Re: JavaMemoryModel: Draft JMM Synopsis

From: Jerry Schwarz (
Date: Mon Mar 08 2004 - 13:14:08 EST

I think a natural way to describe this is

Memory actions in different threads are in general unordered. However the JMM requires that order be established between certain operations and when in a particular execution an order is established in which one action is earlier than another the first action is said to happen-before the second action.
Another point on nomenclature. I've been doing semantics long enough that referring to fields and array members as "variables" seems natural to me, but I think it is confusing for most programmers who think a variable is something they declare in a method or block.

At 02:51 PM 3/7/2004, Doug Lea wrote:
> Always write the term happens-before, i.e., with the hyphen,

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
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.

Initialization Access Atomics Threads
Doug Lea Last modified: Sun Mar 7 17:43:13 EST 2004
------------------------------- JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:59 EDT