[jmm-dev] Enforcing access atomicity (benchmarks)
dl at cs.oswego.edu
Mon Feb 17 06:00:51 PST 2014
On 02/16/2014 07:47 PM, David Holmes wrote:
> I think the non-atomic treatment of long/double unless volatile is so isolated
> in the memory-model, and so stand-alone and simple, that removing it would be
> imperceptible in the overall complexity of the JMM.
True in the JSR133 JMM, but for JMM9, I think we'd like to
equate non-volatile access with relaxed mode of volatile.
To preserve this, we need more modes. Maybe we do anyway.
Stealing a term from clang (http://llvm.org/docs/Atomics.html),
we could use "monotonic", that combines atomicity with not
allowing time to run backwards. Here's how this might fit in to
the One Page Memory Model (that includes a big cheat for now.)
1. A program consists of one or more .class files containing
bytecodes, typically translated from a source language. A program
starts by accessing an object constructed in accord with a given
2. Any read (i.e., a get* bytecode) returns a value written (i.e., a
put* bytecode) by some thread, as constrained by rules below, or in
the absence of well-founded constraints, zero (0/0.0/false/null).
All accesses are guaranteed atomic except for those of long or double
variables that are either non-volatile or accessed in Relaxed mode.
3. The order of (get* put*) bytecodes accessing ordinary variables or
access invocations in lRelaxed mode for volatile variables imposes no
ordering constraints on execution except for the following:
a. Indirect read ordering is always preserved; i.e., any
such read is equivalent to getDependent().
b. Field assignments within constructors are always ordered before
subsequent program-order assignments of references to the
constructed objects; i.e., each such store is equivalent
c. Data-race-free programs using monitor locks are sequentially
consistent. [The big cheat for now.]
4. Explicit ordering control is available using volatiles, fence
methods, and .volatile expressions, as follows, illustrated using the
* Monotonic mode
v.getMonotonic() and v.setMonotonic(x)
given a: v.getMonotonic() and b: v.getMonotonic(),
and a is before b in bytcode order, then it is not the
case that b is ordered before a in any execution. [Etc.]
* Acquire/Release mode.
v.getAcquire() and v.setRelease(x)
* Indirection dependent mode.
v.getDependent(ref) and v.setDependent(x, ref)
[explain as scoped acquire/release...]
* Sequential mode.
v.getSequential() and v.setSequential(x)
5. Other misc: Thread.start etc.
More information about the jmm-dev