[LAD] Atomic Operations

[Olivier Guilyardi]

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?

--
  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/315d8010/attachment.ksh>