On 11 July 2011 21:58, Paul Davis 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...)
Linux-audio-dev mailing list