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

From: Dan Muresan <danmbox@email-addr-hidden>
Date: Mon Jul 11 2011 - 21:59:25 EEST

> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jul 12 00:15:02 2011

This archive was generated by hypermail 2.1.8 : Tue Jul 12 2011 - 00:15:02 EEST