Re: [LAU] Simple, easy multithreaded circular buffer library for Linux?

From: Joern Nettingsmeier <nettings@email-addr-hidden-hochschule.de>
Date: Fri Oct 17 2008 - 21:06:55 EEST

Olivier Guilyardi wrote:
> Paul Coccoli wrote:
>> On Fri, Oct 17, 2008 at 8:46 AM, Paul Davis <paul@email-addr-hidden> 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Sat Oct 18 00:15:03 2008

This archive was generated by hypermail 2.1.8 : Sat Oct 18 2008 - 00:15:03 EEST