My understanding of multiprocessor safety issues is that in general they are
not caused by the caches on current hardware. This is because the hardware
available today maintains cache consistency at a hardware level. It is the
relaxing of write orders that causes most of the problems, and relaxing of
read orders, however rare or common on today's hardware, can cause the same
problems.
The book UNIX Systems For Modern Architectures: Symmetric Multiprocessing
and Caching for Kernel Programmer by Curt Schimmel covers the issues well. I
think this also agrees with what Sarita Adve said in the message
http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0054.html.
The point is that reasoning about how to fix things based on the cache being
the problem is not very useful since on many machines the cache is not the
problem. (This does not keep the cache from ever being the problem.)
I think it is more useful to talk about what operations should be guaranteed
instead of what memory model should be guaranteed. Specifying a memory model
is very subtle and can lead to surprisingly stronger or weaker guarantees
than were intended. If we instead list what behavior should be guaranteed to
be correct, then programmers can spend less time meditating on what a memory
model really implies and more time programming to guaranteed safe rules.
The four rules listed on page 89 of Programming with POSIX Threads by David
R. Butenhof may be a good starting point for a set of rules programmers can
depend on. Since these rules come from pthreads, they have the added
advantage of being something that every hardware architecture is likely to
support (through memory barriers or other operations). These rules are also
listed at the end of my paper on page 10:
http://www.primenet.com/~jakubik/mpsafe/MultiprocessorSafe.pdf
--Paul
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT