9 Jul
2011
9 Jul
'11
1:27 a.m.
On Sat, Jul 09, 2011 at 02:03:34AM +0300, Dan Muresan wrote:
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.
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. 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