I've been putting together a synopsis of new JMM to someday appear in
a section in the 3rd edition of CPJ book. My intent here is to keep it
short, yet complete enough to be suitable for putting on facing pages
of book to keep open by people writing code that depends critically on
model.
Unlike the (very nice) stuff Jeremy Manson and Brian Goetz have been
putting out lately, this section is designed as a cookbook for
non-novice concurrent programmers. (Whatever that means!) It mostly
deals with orderings, since most other aspects will be covered
elsewhere. Also, other subsections (not yet written) will include more
explanatory text; this is just the synopsis. (Note also that this
includes references to some JSR166 stuff too.)
I'm posting this hoping that someone will see problems or have
suggestions for improvement.
===
The Java memory model (JMM) deals mainly with the "memory actions" of
a program -- loads, stores, locks, and unlocks -- where a completed
store action modifies (only) the variable being written, and a
completed load action obtains a value from a completed store action
that does not occur after this load. The notion of a "completed"
memory action reflects the possibility that the effects of some
actions may occur in a different order than they are issued. Loads
and stores for all kinds of variables except non-volatile longs and
doubles are atomic.
Some aspects of the model apply only to subcategories of memory actions:
NORMAL accesses are lads and stores to non-volatile, non-final (static or
nonstatic) fields and array elements.
VOLATILE accesses are loads and stores to volatile (static or nonstatic)
fields. Additionally, java.util.concurrent.atomic compareAndSet
operations act as volatile accesses.
FINAL accesses are loads and stores to final (static or nonstatic) fields.
LOCKS and UNLOCKS are entries and exits of synchronized blocks or methods
The same rules apply to operations on java.util.concurrent.locks.
The JMM allows the memory actions in a program to be performed in
parallel or out of order, subject to the following:
General constraints
* The within-thread expression and statement evaluation dependencies
specified in the Java Language Specification (JLS) are at all
times honored, consistently across all threads. (Rigorously
specifying what is meant by "consistently" in cases that
entail apparent circularities and the like turns out to be
challenging. See JLS chapter 17 for details.)
* A memory action by one thread that cannot influence the actions of
any other thread need not have any memory effect, and can thus be
excluded from remaining rules. (See JLS for a detailed explanation
of "influence".)
Initialization
* The initial action for any field is a store of its default (zero
or null) value. This must complete strictly before any loads of
this field by any thread.
* Any FINAL store to a static final field must complete strictly before
any load of this field by any thread. (There are special
exceptions for setting System.{in,out,err}.)
* Any FINAL store to a nonstatic final field by a thread must complete
strictly before any subsequent store of a reference to the new
object with this field by that thread.
Access
* A NORMAL access by a thread must complete strictly before those of
any subsequent VOLATILE store or UNLOCK by that thread.
* A load of a reference to an object by a thread must complete
strictly before any subsequent load by that thread of any of this
object's FINAL fields.
* A VOLATILE load, LOCK, or compareAndSet by a thread must complete
strictly before any subsequent memory action by that thread.
* A VOLATILE store or UNLOCK by a thread must complete strictly
before any subsequent VOLATILE access, LOCK, or UNLOCK by that
thread.
* A weakCompareAndSet to a variable by a thread must complete
strictly before any subsequent access to that variable by that
thread. (Note: All other memory operations on any variable for
which weakCompareAndSet applies are volatile.)
Threads
* All memory actions by a thread must complete strictly before any
effects of a subsequent invocation of Thread.start() by that thread.
* All memory actions by a thread must complete strictly before
termination of that thread.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:58 EDT