16 Dec
2009
16 Dec
'09
1:50 p.m.
On 12/16/2009 10:43 AM, Tim Blechmann wrote:
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...
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
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. 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 ...