On Wed, Mar 2, 2016 at 5:55 PM, Jonathan Brickman <[email protected]> wrote: > On 3/1/2016 11:40 AM, Paul Davis wrote: > > > the JACK implementation relies on two things to work: > > > > * pointer and integer operations are (weakly) atomic on all platforms > > that JACK runs on > > * code reordering will either not happen or will be prevented by the > > compiler > > Does #2 mean that -O3 should always be avoided when compiling JACK clients?
As I said, I consider JACK's ringbuffer implementation to be broken. According to the C11/C++11 memory model there is nothing in the code that prevents reordering the update to write_ptr and the update to *buf in jack_ringbuffer_write. The use of volatile only makes sure that read/write accesses to the volatile variables are not reordered or "optimized out" by caching. Specificaly, a volatile write is not a release barrier. It does not constrain reordering with respect to other memory locations (*buf). This makes the access to the buffer's content unordered and invokes undefined behaviour. Having said that, if you can be sure that the compiler does not reorder this (by checking the assembly code, for example) then you will be fine on an x86/x64 platform because this platform makes an extra guarantee: writes in one thread are never seen out of order from another thread's perspective. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
