4 Mar
2016
4 Mar
'16
10:16 a.m.
On Wed, Mar 2, 2016 at 5:55 PM, Jonathan Brickman <jeb(a)ponderworthy.com> wrote:
On 3/1/2016 11:40 AM, Paul Davis wrote:
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.
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?