On Tue, Mar 1, 2016 at 12:09 PM, Sebastian Gesemann <s.gesem...@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".
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev