linuxaudio.org

On Fri, Oct 17, 2008 at 1:20 PM, Olivier Guilyardi  wrote:

quoted text
> Paul Coccoli wrote:

>> On Fri, Oct 17, 2008 at 8:46 AM, Paul Davis  wrote:

>>>

>>> 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.

>>

>> 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.

>

> Well, it looks like you had a fast but great insight here. I've turned all

> statements of this kind into one-liners, and the jack ringbuffer now

> (apparently) passes the test.

>

Looks like I don't have to "step back" or "read the whole thread for

links to relevant documents" then ;)
> Here's the patch against jack1 r3007:

quoted text
> http://svn.samalyse.com/misc/rbtest/patches/jack-r3007-rb-fix.diff

>

> And thanks everyone for the tests ! I've updated the test suite, it now contains

> an additional test with this patch. Please continue testing :)

>

I didn't test your patch, but my own patch (which is the same thing)

works on dual Core2 duo system, whereas the original didn't.
No memory barriers needed *on x86* (volatile isn't needed anywhere).

Others system probably need memory barriers.

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user