> Always write the term happens-before, i.e., with the hyphen,------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
Thanks. I had just tried that, plus using italics. Together this seems
to just barely avoid seeming like you are vacuously saying that
something happens before something it happens before. Attached in
html. Updates at http://gee.cs.oswego.edu/dl/cpj/JMMsynopsis.html
Further comments always welcome.
JMM Synopsis
(This is draft of a part of a section for the 3rd edition of CPJ on the JDK1.5 memory model.)
The Java Memory Model (JMM) may be seen as an extension of the basic within-thread expression and statement evaluation rules described in the bulk of the Java Language Specification (JLS). For example, JLS expression rules state that a given thread evaluates any expression left to right. The JMM provides additional rules governing whether the "memory actions" in one or more threads of a program may be performed in parallel or out of order.
Memory actions are reads, writes, locks and unlocks, along with operations on java.util.concurrent.atomic variables. A write corresponds to the assignment of a variable (i.e., field or array element) that modifies (only) that variable, and a read obtains a value from some write that does not happen after this read. Reads and writes for all kinds of variables except non-volatile longs and doubles are atomic, that is reads never return the values from partially completed writes. Lock and unlock actions are entries and exits of synchronized blocks or methods, or explicit lock() and unlock() operations on java.util.concurrent.locks.
The JMM is defined in terms in terms of a happens-before relation that provides ordering rules for the effects of memory actions. If action A happens-before action B, then compilers, processors, and memory subsystems must preserve the ordering of their effects. For example, if A is a write and B is a read of the variable written, and the pair fall under the happens-before relation, and there are no other intervening writes, then the read in action B must return the value written in action A. But if the pair does not fall under this relation, then the read might or might not return this value.
The happens-before relation extends the JLS within-thread expression and statement evaluation rules, so these rules 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 these and other details, many of which describe minimal properties of code that is not correctly synchronized, as well as other corner cases that are best avoided. More relevantly, the following rules derived from the specification may be of use when ensuring that code is correctly synchronized.
InitializationAccess
- The initial action for any field is a write of its default (zero or null) value that happens-before any reads of this field by any thread.
- The write to a static final field happens-before any read of this field by any thread. (There are special exceptions for setting System.in, out, and err.)
- The write to a non-static final field by a thread happens-before any subsequent write of a reference to the new object with this field by that thread.
Atomics
- An unlock or volatile write to a variable happens-before any subsequent lock of that lock or volatile read of that variable.
- A volatile read or lock by a thread happens-before any subsequent memory action by that thread.
- Any memory action by one thread happens-before any subsequent volatile write or unlock by that thread, with respect to any other thread that reads the same volatile variable or locks the same lock.
- The first read of a reference to an object by a thread happens-before any subsequent read by that thread of any of the object's final fields.
Threads
- The effects of a java.util.concurrent.atomic get() operation are the same as a volatile read, and those of a set() are the same as a volatile write.
- A weakCompareAndSet by a thread happens-before any subsequent access to that atomic variable by that thread.
- The effects of a compareAndSet, along with other atomic read-and-update methods, fall under the memory rules for a volatile read followed by a write.
- Any write by a thread performed prior to invoking Thread.start() for a new Thread happens-before those of any reads of these written variables by that new Thread.
- Any write by a thread happens-before termination of that thread. (Another thread can only reliably detect termination by using Thread.isAlive() or Thread.join().)
Doug Lea Last modified: Sun Mar 7 17:43:13 EST 2004
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:59 EDT