Re: [LAD] Atomic Operations

On 12/16/2009 10:43 AM, Tim Blechmann wrote:
>>>> this was discussed at some considerable length on jack-devel last
>>>> year, IIRC.
>>>> for single reader/single writer ringbuffers, i believe that we
>>>> concluded that memory barriers are not necessary.
>>> No, to me the conclusion was: we can't programmatically prove that
>>> memory
>>> barriers are needed (even on the most vulnerable architectures),
>>> but the theory
>>> say that they are, and they should be added for correctness.
>> My understanding matches Olivier's. Intel processors have strong memory
>> ordering, and so on them the jack ringbuffer is safe without memory
>> barriers. However, some PPC processors, and SPARC V9s under linux
>> (but not
>> Solaris), use weak memory ordering, and on them, the jack ringbuffer
>> code
>> can theoretically fail.
>
> exactly, the issue may not appear on x86, because of its memory
> consistency, weakly-ordered machines will need some barriers ...

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

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

It shouldn't be so complex to fix in jack I guess.

--
  Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev