On Friday 08 July 2011 20:12:08 Gabriel M. Beddingfield wrote: > On Friday, July 08, 2011 12:17:34 pm Fons Adriaensen wrote: > > On Fri, Jul 08, 2011 at 09:21:55AM -0400, Paul Davis > > wrote: > > > 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. > > > > AFAIK nothing fatal can happen if the variables involved > > are declared volatile. A compiler is not allowed to > > omit, repeat, or re-order instructions involving them. > > Take for instance jack_ringbuffer_read(), which has this > line: > > rb->read_ptr = (rb->read_ptr + n) & rb->size_mask; > > There's a remote possibility that the compiler could > optimize this as: > > rb->read_ptr += n; > rb->read_ptr &= rb->size_mask; > > ...and this would break the ringbuffer. I don't know if the > `volatile` keyword prevents this or not.
What would happen? The ringbuffer in jack is explicitely only for one-reader- one-writer. So in this optimization, the only participant using the read_ptr to do something possibly bad, is the reading participant which is currently executing this code. The writing participant can access that read_ptr for example to check the available space. But as the docs state (afair), the available sizes for read/write are not strict functions, the only thing that counts is if you have space for reading/writing. And that is fulfilled if read_ptr!=write_ptr... Have fun, Arnold
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
