compiler memory barrier and mutex

Question

posix standard says that things like mutex will enforce a memory sync. However, the compiler may reorder the memory access. Say we have

lock(mutex);
setdata(0);
ready = 1;
unlock(mutex);

It might be changed to code below by compiler reordering, right?

ready = 1;
lock(mutex);
setdata(0);
unlock(mutex);

So how can mutex sync the memory access? To be more precise, how do compilers know that reordering should not happen across lock/unlock?

actually here for single thread aspect, ready assignment reorder is totally safe since ready is not used in function call lock(mutex).

EDITED: So if function call is something that compiler will not get across, can we regard it as a compiler memory barrier like

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

Answer 1

General answer is that your compiler should support POSIX if you want to use it for POSIX targets, and that support means it should know to avoid reordering across lock and unlock.

That said, this kind of knowledge is commonly achieved in a trivial way: compiler would not reorder access to (non-provably-local) data across a call to an external function which may use or modify them. It should have known something special about lock and unlock to be able to reorder.

And no, it's not that simple as "a call to global function is always a compiler barrier" -- we should add "unless the compiler knows something specific about that function". It does really happen: eg pthread_self on Linux (NPTL) is declared with __const__ attribute, allowing gcc to reorder across pthread_self() calls, even eliminating unnecessary calls altogether.

We can easily imagine a compiler supporting function attributes for acquire/release semantics, making lock and unlock less than a full compiler barrier.

Answer 2

Compilers will not reorder things where it is not clear that it is safe. In your "what if" example, you are not proposing a reordered memory access, you're asking what if the compiler totally changes the code ordering -- and it won't. Something the compiler might do is change the order of actual memory reads/writes but not function calls (with or without respect to those memory accesses).

An example of where the compiler might reorder memory access... lets say you have this code:

a = *pAddressA;
b = *pAddressB;

and lets consider the case where the value of pAddressB is in a register while pAddressA is not. It's fair game for the compiler to read address B first, then move the value of pAddressA into that same register so that the new location can be received. If there happens to be a function call between these accesses, the compiler cannot do this.