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

On Fri, Jul 8, 2011 at 7:24 AM, James Morris <jwm.art.net(a)gmail.com> wrote: 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.