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

[Fons Adriaensen]

On Sat, Jul 09, 2011 at 02:03:34AM +0300, Dan Muresan wrote:
> > Better to just follow the recommendations of the respective ABIs,
> > and put in the memory barriers for those platforms that need them,
> > like PortAudio, the linux kernel, and most other implementations
> 
> The apps already need to do some type of synchronization internally.
> For example a player's disk thread, when its ringbuffer is full, needs
> to wait for the process thread to consume some data and thus free up
> some space.

Depends. If both ends are periodic processes no other synchronisation
is required. And e.g. Jack callback is such a process, and likely to
be one end.
 
> So I think it would be better to drop the volatile's, and leave safety
> to the app level. There's no point in duplicating synchronization at
> the library and at the app level.

You may be right about the (HW as opposed to compiler) re-ordering of
data w.r.t. pointers on some architectures. But AFAIK, at least on Intel
and AMD writes are not re-ordered w.r.t. other writes from the same CPU,
same for reads.

Regarding the volatile declarations, at least on my version (which
is slightly different from Jack's) there is no performance penalty.
So I keep them just as reminders that these data are shared and may
change in unexpected ways.

You are wrong in saying that 'volatile' has no place in multi-threading.
It is the correct way to go if you want to ensure that a value is e.g.
read/written just once even if it is used many times:

extern volatile int xval;  // Written by other thread(s)

void f (void)
{
    int x;

    x = xval;
 
    // use x many times, it won't change.
}

Without the 'volatile', the compiler is free to read
the memory value xval as many times as it wants, even
if it has a local copy, and it probably will do so if
you have many local variables.

Ciao,

-- 
FA