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