17 Oct
2008
17 Oct
'08
10:56 a.m.
On Fri, Oct 17, 2008 at 8:46 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Fri, 2008-10-17 at 14:13 +0200, Olivier Guilyardi
wrote:
Why do you suspect you need memory barriers? My concern with
ringbuffer.c is the non-atomic ops on the read and write pointers.
They're marked volatile, but what I think you really want is make all
ops on those fields atomic. Stuff like this:
rb->read_ptr += n1;
rb->read_ptr &= rb->size_mask;
Looks like a problem to me. What happens if there's a context switch
in between those 2 statements?
NB: I only took a cursory glance at the code.
Okay, I wrote such a test. It fails with
Jack's ringbuffer (jack1 r3004) but
succeeds with Portaudio's one (r1240).
Nice work. Nobody ask why we didn't do this 5 years ago!
The Portaudio code looks more and more robust to
me. It's also surprisingly
short. Maybe that the best would be to replace jack's ringbuffer with it? I
think it should be possible to keep the jack_ringbuffer api unchanged.
I'd rather add the memory barriers to the JACK code, but this could be a
race to see who does what first. A memory barrier is typically single
instruction. The complication tends to be defining them in a
sufficiently portable way.