互斥锁可以取代内存障碍吗

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

内存条通常用于使功能混乱的流水线相对于其内存访问进入定义良好的状态，因此与互斥量的概念正交，互斥量的概念通常在多处理中是更高得多的概念（与CPU指令的乱序执行无关）。

Answer 3

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