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

[Arnold Krille]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20110708/fa4098e5/attachment.pgp>