Can mutex replace memory barriers

Question

I was trying to understand memory barrier and came across the below wikipedia link http://en.wikipedia.org/wiki/Memory_barrier This explain the concept well but had thoughts if this is really helpful in system where we have mutex() locking the memory section.

Taking the same code as mentioned in wikipedia, will the below approach solve the problem using mutex?

[Note: Function names are not specific to any programming language, just used for simplicity sake]

Processor #1

mutex_lock(a)
while (f == 0);
print x;
mutex_unlock(a)

Processor #2

mutex_lock(a)
x = 42;
f = 1;
mutex_unlock(a)

Answer 1

A memory barrier guarantees that all visible effects of prior instructions become observable before those of any subsequent instructions. Things that might reorder the observed order of effects are:

• Compilers (by reordering instructions)
• Out of order pipelines
• Cache systems with relaxed memory consistency (practically all on modern systems)

A mutex guarantees that only one thread holds the mutex at a time.

There is a relationship between the two concepts: a mutex is practically useless without at least partial memory barriers. Consider this example:

mutex_lock(a);
x = x+1;
mutex_unlock(a);

The lock operation must have at least an "acquire" barrier that prevents the load of x from appearing to happen before the lock is acquired. Likewise, the "unlock" operation must have at least a "release" barrier that prevents the store of x from appearing to happen after the lock is released. That is the lock-unlock pair form a cage from which operations cannot escape. (Though sometimes programmers are surprised when reordering causes operations to crawl into the cage!)

So locking a mutex and immediately unlocking it acts as a memory barrier, albeit a horribly inefficient one since it forces serial execution.

Answer 2

Mutex and other lock in kernel uses the barrier internally to ensure that code runs in the exact order as expected. When using optimization in compliers, You should never assume that instructions will be performed in the exact same order as written in the source code. Compiler might reorder the assembly language instructions in such a way to optimize how registers are used. Moreover, modern CPUs usually execute several instructions in parallel and might reorder memory accesses. These kinds of reordering can greatly speed up the program. But can result into unexpected output!

Hence MEMORY BARRIER primitive ensures that the assembly language instructions corresponding to C statements placed before the primitive are not mixed by the compiler with assembly language instructions corresponding to C statements placed after the primitive. In linux barrier() macro is:

asm volatile("":::"memory")

Here is the explanation:

1. asm instruction tells the compiler to insert an assembly language fragment
2. volatile keyword forbids the compiler to reshuffle the asm instruction with the other instructions of the program
3. The memory keyword forces the compiler to assume that all memory locations in RAM have been changed by the assembly language instruction; therefore, the compiler cannot optimize the code by using the values of memory locations stored in CPU registers before the asm instruction

Answer 3

A memory bar usually is used to get out-of-order capable pipelines into a well-defined state with respect to their memory accesses, and thus are orthogonal to the concept of mutexes, which typically are a far much higher-level concept in multiprocessing (and have nothing to do with out-of-order execution of CPU instructions).