linuxaudio.org

On Sat, Jul 09, 2011 at 02:03:34AM +0300, Dan Muresan wrote:

quoted text
> > 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

quoted text
> 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
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev