the hardware would be allowed to reorder them ... this
is the reason why mutex
implementations involve memory barriers ...
Yes, the hardware would be allowed to reorder them, so
pthread_mutex_lock() has memory barriers. I think everyone knew that
much :)
However my point to Fons was that, because pthread_mutex_lock() is an
external function, the compiler is not allowed to make any assumptions
about the global variable x (both functions might modify it): it
cannot re-read x after unlock(), or read x before lock(). This was the
missing ingredient.
So it's a cooperation of sequence point-rules and memory barriers that
achieves the effects of a critical section in C.
the main problem is the lack of a memory model for
multi-threaded applications
at the level of the language (c or c++). fortunately this is about to change
with c++0x and probably c1x.
So in 10 years we will be able to rely on a conformant compiler being
available on all relevant platforms :)
-- Dan