> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jul 11 00:15:02 2011
This archive was generated by hypermail 2.1.8 : Mon Jul 11 2011 - 00:15:02 EEST