JavaMemoryModel: Semantics of locks and volatiles

From: Bill Pugh (
Date: Wed Jun 27 2001 - 21:59:28 EDT

The basic informal proposal for the semantics of locks and volatiles
is release consistency, as well documented in a number of technical
papers. Sarita or others can probably correct all the subtleties I am
going to get wrong, but basically:

   * volatile writes and monitor exits are treated as synchronization releases.

   * volatile reads and monitor enters are treated as synchronization acquires.

A synchronization release action and _a matching_ synchronization
acquire action establish a "happens before" relationship between the
two threads. Program order within a thread also establishes a happens
before relationship, and "happens before" is transitive.

If two threads access the same normal field or array element, and one
of those accesses is a write, the accesses conflict. For any two
conflicting accesses, there should be a "happens before" relationship
between the two accesses. If all sequentially consistent executions
of a program are correctly synchronized (i.e., all conflicting
accesses are ordered), then the program is correctly synchronized and
follows sequentially consistent semantics.

This allows a number of compiler optimizations, including:

   * If a object is only ever locked by a single thread, the lock
operations are no-ops.

   * Reentrant locks are no-ops.

   * Lock coarsening is legal, although quality of service issues are
raised and need to be addressed

   * accesses to normal variables can be reordered with
        - a following volatile read or monitor enter
        - a preceding volatile write or monitor exit

    * volatile variables accessed from only a single thread can be
treated as normal variables.

Comments or questions?

JavaMemoryModel mailing list -

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