11 Jul
2011
11 Jul
'11
3:34 a.m.
On Jul 10, 2011, at 2:41 PM, Paul Davis wrote:
On Sun, Jul 10, 2011 at 5:14 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Yes. PowerPC and Alpha do not. UltraSPARC v9 and ARMv6/ARM11 and later
have modes where they do not (and linux on a SPARC v9 runs in that
mode.)
Here's some good reading that may help:
Memory Ordering in Modern Microprocessors, Part I
http://www.linuxjournal.com/article/8211
Memory Ordering in Modern Microprocessors, Part II
http://www.linuxjournal.com/article/8212
Linux Kernel Memory Barriers
http://www.kernel.org/doc/Documentation/memory-barriers.txt
ARM11 Processors: Ordering requirements for memory accesses
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211i/Babcijbf.html
On that I absolutely agree - cache coherency is
the real
problem, not pipelining. The latter should in fact be
transparent from a language such as C/C++.
i may be way out of the loop, but having worked with some of the early
"massively" parallel "conventional processor" systems of the late
80's
and early 90's (such as the sequent symmetry and the kendall square
research machines), my impression was that everyone gave up on
"clever" cache coherency because it turned out to be too hard (as an
engineering problem, not as a CS problem). i've gotten stuck with the
idea that the industry went for "simple" cache coherency that simply
does what any moderately skilled designer would do when faced with the
problem and no concerns about elegance or speed: locks, signalling,
and all the usual stuff that is the h/w equiivalent of the pthreads
mutex API.
do we have SMP systems these days that do not guarantee cache
coherency? btw: i do understand that whether they do or do not
doesn't affect the
basic point about cache coherency possibly leading to incorrect data
being read.
Good--without memory barriers, JACK's ringbuffer is at risk
for this corruption on these platforms.
Cheers,
-Sean