[LAD] a *simple* ring buffer, comments pls?

[Paul Davis]

On Fri, Jul 8, 2011 at 7:24 AM, James Morris <jwm.art.net at gmail.com> wrote:

> While I thought my rbuf was broken I read about how lock-free code is
> not really lock-free, it just uses very fine grained locking.
> http://stackoverflow.com/questions/2528969/lock-free-multi-threading-is-for-real-threading-experts/2530082#2530082

we've been through this several times on LAD-related mailing lists.

the usability of a lock free ringbuffer does NOT rely on the stuff
discussed in that article.

the reason it works is because even if there is a sync error between
threads, the error has no negative consequences. put differently, a
lock free ringbuffer does not rely on two threads interacting in a
particular way, it relies on the fact that if they interact in the
"wrong" way, all that happens is that the reader sees less data to
read than actually exists, and/or the writer sees less space to write
than is actually available. if your application views this as a
"negative", then it will have to use some kind of locking primitives
to avoid it, but most audio applications can deal with this without
blinking.

this is entirely different from more generic lock free programming
techniques (e.g. lock free lists) where it is definitely true that you
need to understand memory barriers and so forth to ensure that they
are safe). its also important to recognize that the "locks" used by
memory barriers are processor-level, and not really equivalent in most
senses to the locks used by the kernel or user space. they do have the
capability to block a thread, but the delay is measured in
instructions (mostly) and does not involve process-level information.

the one wrinkle in this is that in theory a compiler could so
completely reorder instructions that even the basic assumptions that
make the single reader/single-writer ringbuffer safe would break down.
this is theoretically possible (and actually, not that hard to create
in practice if you were really trying to) but as oliver mentioned,
we've done some fairly exhaustive testing that when combined with a
moderately common sense approach to compiler design (e.g. the
existence of function scope and related stuff) makes it fundamentally
not worth worrying about this theoretical possibility.