On 11 July 2011 21:58, Paul Davis <[email protected]> wrote: > On Mon, Jul 11, 2011 at 4:50 PM, Chris Cannam > <[email protected]> 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
