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

Dan Muresan danmbox at gmail.com
Mon Jul 11 18:59:25 UTC 2011


> This reordering cannot be prevented without proper synchronization. So
> my advice to anyone considering this would be to drop volatile and do
> proper synchronization at the application level (i.e. semaphores,
> since it has to work in real time).

After this whole round of discussions, it's starting to dawn on me
that not even semaphores might be enough for synchronizing the actual
data in the ringbuffer (never mind the ringbuffer pointers). I assumed
all sem_*() operations performed memory barriers, but POSIX is quite
vague:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11

(what is a "thread of control" when using counting semaphores? A
thread has exclusive access only when the semaphore is 0, but a
counting semaphore could always hover above 3.)

and the NPTL code in glibc *seems* to perform a memory barrier only on
sem_post().

Does anyone know what kind of memory-barrier guarantees counting
semaphores are supposed to offer?

-- Dan



More information about the Linux-audio-dev mailing list