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 - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT