linuxaudio.org

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.

excuse my chiming in here, i'm not really much of a c programmer... but

how can this

  -  rb->read_ptr += n1;

  -  rb->read_ptr &= rb->size_mask;

  +  rb->read_ptr = (rb->read_ptr + n1) & rb->size_mask;

fix anything?
iiuc, both versions are equivalent. a context switch could happen just

as well after the parenthesis has been computed..!?

putting stuff on one line doesn't make it atomic. maybe you are now

getting another compiler optimization that helps to hide the bug?
no offense, just trying to learn something...
jörn
--

jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/

http://spunk.dnsalias.org

phone://+49/201/491621
Kurt is up in Heaven now.

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

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