Synchronization with respect to the memory model

Question

Hi
Can anyone give paste me a link (other than to the JLS itself) that describes the meaning of synchronization with respect to the memory model rather than simply as a means of mutual exclusion?
You read that without synchronization different threads can have inconsistent views of what should be the same data. The link below talks of this issue but says 'the causes of memory consistency errors are complex and beyond the scope of this tutorial.'
http://java.sun.com/docs/books/tutorial/essential/concurrency/memconsist.html
Many thanks
Bruce

Answer 1

There are many articles and a few book chapters or
parts thereof that deal with the new memory model,
and of course some key websites. The primary website
is:
http://www.cs.umd.edu/~pugh/java/memoryModel/
Brian Goetz has written a number of articles on IBM's
DeveloperWorks, and of course this is covered in
great depth in "Java Concurrency in Practice" by
Goetz et al.
I also covered it in the threading chapter of "The
Java Programming Language, 4th edition". :)
A few key points:
- access to volatile long/double has always been
atomic (old JMM and Java 5 JMM), but remeber that
access means a simple read, or a simple write,
something like ++ is not atomic because it is a read
followed by a write
- don't think of this in terms of "caches" - that
will lead to the wrong reasoning. It isn't about
flushing caches or writing to main memory (that was
the old conceptual model that just gets people into
trouble because they keep trying to reconcile it with
how the hardware chaching works). The new memory
model is all about establishing happens-before
relations ships between writes and reads of a
variable, so that the value allowed to be returned
from a read is the most recent value that was
written.
I was under the belief that the previous MM was writen in the way that it was in order to allow flexibility in terms of instuction/read/write reordering, caching, synch block merging and any number of other things that may occur, such that vm's on various architectures could be written efficently.
Of course it could have been that vm writers on those various architectures took advantage of the slack nature of the spec to implement all of those non-standard interpretations of the spec :). Its definately a good thing that the spec has been redefined to make it clearer exactly what a java develper should expect.
- the definitive source for this is actuall the
JSR-133 specification. Chapter 17 of the JLS 3e is
based on that spec but doesn't contain the full
details. (But you are better off reading Ch17 than
the proper spec :) )matfud