Hi, Nikita,

On Oct 21, Nikita Malyavin wrote:
>
> > > > Did you think it's expensive or did you benchmark that?
> > > I did, actually! (in the past). Taking a mutex needs to reserve
> > > the associated cache line, which is not free. "Expensive" is
> > > relative, of course.
> >
> > I'm sure it's an implementation detail.
> > But I've just looked on my laptop and the mutex lock was
> >
> >   lock cmpxchg
> >
> > so, it's a bus lock, indeed, not cheap.
> >
> It's never a bus lock on the modern implementations, it rather
> specifies the operation to execute atomically.

  Causes the processor’s LOCK# signal to be asserted during execution of
  the accompanying instruction (turns the instruction into an atomic
  instruction). In a multiprocessor environment, the LOCK# signal
  insures that the processor has exclusive use of any shared memory
  while the signal is asserted.

This is from the "IA-32 Intel® Architecture Software Developer’s Manual
Volume 2A: Instruction Set Reference, A-M", that can be downloaded from
intel.com.

8.1.4 Effects of a LOCK Operation on Internal Processor Caches
For the Intel486 and Pentium processors, the LOCK# signal is always asserted on the bus during a LOCK operation, even if the area of memory being locked is cached in the processor. 

For the P6 and more recent processor families, if the area of memory being locked during a LOCK operation is cached in the processor that is performing the LOCK operation as write-back memory and is completely contained in a cache line, the processor may not assert the LOCK# signal on the bus. Instead, it will modify the memory location internally and allow it’s cache coherency mechanism to ensure that the operation is carried out atomically. This operation is called “cache locking.” The cache coherency mechanism automatically prevents two or more processors that have cached the same area of memory from simultaneously modifying data in that area.