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

[Chris Cannam]

On 11 July 2011 21:58, Paul Davis <paul at linuxaudiosystems.com> wrote:
> On Mon, Jul 11, 2011 at 4:50 PM, Chris Cannam
> <cannam at all-day-breakfast.com> wrote:
>> Perhaps the pragmatic solution is to _lock_ the shared buffer?
>
> no, the pragmatic solution is to use memory barriers liberally applied.

Well OK, the vital library ringbuffer implementation that everyone
relies on is probably a bad place to start arguing for doing things
the wrong but easy way rather than the right way.

But I know my limitations (increasingly as I get older!) and reasoning
accurately about the behaviour of lock-free shared structures in a
system with relaxed memory ordering is probably among them.  My
existing code contains plenty of consequences of "oh, we don't need a
lock here because..." fuzz that won't work correctly in such an
environment.  I do wonder whether there isn't going to be increasingly
a case for doing it wrong in principle (through locking) but at least
getting the right answers.

Reading around for lock-free FIFO implementations I see several that
consist of "sequences of objects" (where the objects are allocated
outside the scope of the example) that rely on a single atomic
operation to update the read index -- that wouldn't be an adequate
barrier for the data itself in our buffer-of-floats, though, right?
We need a general write barrier after storing the data and before
updating the read index, yes?  how is that expressed as portably as
possible?  Does __sync_synchronized reliably do that?  (The
documentation is surprisingly short...)


Chris