[jmm-dev] Enforcing access atomicity (benchmarks)

[Doug Lea]

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

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
      to field.setDependent(constructedObject).
   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
.volatile form:
   * 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)
     [explain...]
   * Indirection dependent mode.
     v.getDependent(ref) and v.setDependent(x, ref)
     [explain as scoped acquire/release...]
   * Sequential mode.
     v.getSequential() and v.setSequential(x)
     [explain...]

5. Other misc: Thread.start etc.