On Tue, Mar 1, 2016 at 12:09 PM, Sebastian Gesemann <s.gesemann@gmail.com> wrote:

It depends on what meanings you attach to the words "atomics" and
"atomicity". I was trying to use the term "atomic" in a way consistent
with the C11/C++11 memory model. In this context, atomicity is not
only about having logically multiple operations done as a single one
(fetch-and-add, compare-and-swap, etc) but it also involves memory
ordering hints (defaulting to sequential constistency but weaker
models are possible). So, it seems to me that you were not familiar
with this. I said I have little experience with lock-free programming
but that does not mean I'm completely unaware of the theoretical
aspects.

the evil that lock-free data structures seek to avoid is mutual exclusion that involves stopping thread execution. they do not require that things are atomic in either the weak or strong sense, but they do require that the data structures remain consistent and accurate from the POV of the threads that use them.

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

the first assumption is a strong one, and the second one is at best weak, and at worst actually incorrect.

the implementation inside Ardour uses glib's atomic wrappers to make the second assumption strong.

https://github.com/Ardour/ardour/blob/master/libs/pbd/pbd/ringbuffer.h

(there is also a non-power-of-two size version one level up).

Well, for me, that's part of the fun -- figuring out how it's supposed
to be written without invoking U.B.

"Never let what you are really seeking to accomplish interfere with deepening your knowledge of computer science".