Question

When objects are locked in languages like C++ and Java where actually on a low level scale) is this performed? I don’t think it’s anything to do with the CPU/cache or RAM. My best guestimate is that this occurs somewhere in the OS? Would it be within the same part of the OS which performs context switching?

I am referring to locking objects, synchronizing on method signatures (Java) etc.

It could be that the answer depends on which particular locking mechanism?

Answer 1

Locking involves a synchronisation primitive, typically a mutex. While naively speaking a mutex is just a boolean flag that says “locked” or “unlocked”, the devil is in the detail: The mutex value has to be read, compared and set atomically, so that multiple threads trying for the same mutex don’t corrupt its state.

But apart from that, instructions have to be ordered properly so that the effects of a read and write of the mutex variable are visible to the program in the correct order and that no thread inadvertently enters the critical section when it shouldn’t because it failed to see the lock update in time.

There are two aspects to memory access ordering: One is done by the compiler, which may choose to reorder statements if that’s deemed more efficient. This is relatively trivial to prevent, since the compiler knows when it must be careful. The far more difficult phenomenon is that the CPU itself, internally, may choose to reorder instructions, and it must be prevented from doing so when a mutex variable is being accessed for the purpose of locking. This requires hardware support (e.g. a “lock bit” which causes a pipeline flush and a bus lock).

Finally, if you have multiple physical CPUs, each CPU will have its own cache, and it becomes important that state updates are propagated to all CPU caches before any executing instructions make further progress. This again requires dedicated hardware support.

As you can see, synchronisation is a (potentially) expensive business that really gets in the way of concurrent processing. That, however, is simply the price you pay for having one single block of memory on which multiple independent context perform work.