4 ms·
How is a mutex lock less expensive than a memory access? Are such things done only in registers nowadays? This doesn't sound right.
by SeanLuke 14y ago
How is a mutex lock less expensive than a memory access? Are such things done only in registers nowadays? This doesn't sound right.
- haberman 14y agoLess expensive than a main memory access. It must be that an uncontended lock/unlock can happen in cache.
- JoeAltmaier 14y agoNo definitely not. A full memory fence surrounds lock/unlock.
- scott_s 14y agoI actually don't think that's true. My understanding is that on x86, atomic instructions have implicit lock instructions before them. (Or you can make some instructions atomic by putting a lock instruction before them.) Such instructions lock the bus and prevent other cores or SMT threads from accessing memory. In that way, you can safely perform an atomic operation on a value in the cache. Note that this implies that atomic operations slow down others cores and SMT threads.
- JoeAltmaier 14y agoLocks are often implemented using an xchg instruction, which is implicitely locked. All processor's caches are committed/flushed for the affected cache line. So its correct to say other processors are slowed down. But it also in that sense IS a main memory operation, just not yours.
- scott_s 14y agoTo be clear, then we agree that haberman was correct, and the value can be changed in cache.
- JoeAltmaier 14y agoSure. It just isn't useful in cache. If it is a real lock, it has to be shared. Either the caches have to reconcile, or it has to go to main memory.
- scott_s 14y agoIt's useful for fields (not just locks; I'm thinking of lock-free algorithms that do a compare-and-swap directly on a value) that have low contention.
- JoeAltmaier 14y agoEven uncontended, the value has to be reconciled between cpus/caches. So it has to be plumbed down thru all the caches, then back up.
- scott_s 14y agoThat's my point: uncontended values may not be in any other caches.
- haberman 14y agoJust because a lock is shared does not mean that it's contended. For example, some multi-threading techniques attempt to access only CPU-local data but use locks purely to guard against the case where a process is moved across CPUs in the middle of an operation (thus defeating the best-effort CPU-locality).
- JoeAltmaier 14y agoBut it has to be available to those multiple cpus, right? So it has to go down to memory and back up to cache. Contended or not.
- haberman 14y ago
- a-priori 14y agoI assume that the mutex's memory is warmed, so the processor doesn't have to go to RAM. But, it does have to synchronize with any other processors/cores in the machine to prevent them from locking the mutex at the same time. In a Intel Nahalem or Sandy Bridge system, this goes over the QuickPath Interconnect which has a latency of ~20ns. HyperTransport fills the same role in AMD systems, and probably has a similar latency, but I don't have numbers for that. I'm basing this on this presentation, especially the architecture diagram at 2m 40s: http://www.infoq.com/presentations/Lock-free-Algorithms http://www.infoq.com/presentations/Lock-free-Algorithms