[LAD] Atomic Operations

[Olivier Guilyardi]

On 12/17/2009 12:40 PM, Olivier Guilyardi wrote:
> On 12/16/2009 06:57 PM, Tim Blechmann wrote:
> 
>>> The point is, I wrote ringbuffer stress tests, and someone reported on this list
>>> that they succeeded on a weakly-ordered (PowerPC SMP) system, even without
>>> memory barriers. Anyway...
>> unfortunately stress tests won't necessarily show the race condition
> 
> My tests helped to find and fix a race bug in jack ringbuffer. I guess this
> should have worked for memory barriers too. Unless they need to run for a
> century before an error occur.. ;)
> 
>>>>> See the "ring buffer memory barriers" discussion on jack-devel back in
>>>>> October of last year for more information; in particular, this article
>>>>> by Paul E. McKenney is very helpful:
>>>>>
>>>>> http://www.linuxjournal.com/article/8211
>>>> memory-barriers.txt of the linux kernel documentation is interesting as
>>>> well ...
>>> The portaudio ringbuffer is also a good source of inspiration I think:
>>> http://portaudio.com/trac/browser/portaudio/trunk/src/common/pa_ringbuffer.c
>>>
>>> In short, they use memory barriers at only three places, especially:
>>>
>>> - "to ensure that previous writes are seen before we update the write index"
>>> - "to ensure that previous writes are always seen before updating the (read) index."
>> the kfifo doesn't look too different, either ...
> 
> Okay, I got a patch for Jack1's ringbuffer, it's not finished, but it's a
> beginning. I think it misses some "read" memory barriers, as described in
> kernel's memory-barriers.txt (in SMP BARRIER PAIRING) : "A write barrier should
> always be paired with a data dependency barrier or read barrier[...]".
> 
> It's attached. What do you think?

Oups, sorry, ignore my previous patch. It contained an obvious bug in
jack_ringbuffer_read() and jack_ringbuffer_write(). See the new one, attached.

--
  Olivier
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ringbuffer-mb.diff
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20091217/a45cad39/attachment.ksh>