> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
