11 Jul
2011
11 Jul
'11
8:59 p.m.
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…
(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