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

On 11 July 2011 21:58, Paul Davis <paul(a)linuxaudiosystems.com> wrote: 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