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. Okay, it doesn't say "a bus lock" explicitly anymore.
Normally it will be synchronized through MESI, unless the memory is not cache-line-aligned, or is marked as non-cacheable.
These are two completely different issues. How changes are synchronized and how atomicity is implemented. Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org