Re: [LAD] a *simple* ring buffer, comments pls?

From: Dan Muresan <danmbox@email-addr-hidden>
Date: Sun Jul 10 2011 - 20:26:36 EEST

> 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