atomicity for value types

[John Rose]

On Jan 14, 2020, at 4:52 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> In the context of Java, we are already using the term 'atomic', in AtomicInteger, AtomicLong, etc,

Even more fundamentally, the term “atomic” is in the JLS, JVMS, and JMM
with the same meaning being proposed here, and *not* subsumed by nor identical
with “volatile”.

JMVS 4:

> Untyped instructions that manipulate the operand stack must treat values of type long and double as atomic (indivisible).

JLS 17.7. Non-Atomic Treatment of double and long:

> Writes and reads of volatile long and double values are always atomic… Writes to and reads of references are always atomic…

And JMM has more of the same.

> and in that case the semantics is volatile + atomic operations (at least CAS), so i think using atomic or any keyword derived from it will not help to our users to understand the semantics for an inline class.

So volatile is associated with atomic, but it is not identical.
You came up with an interesting example of that association,
the AtomicLong API, but it’s just an association.  Nobody will be
confused.

> As Doug said, for a VarHandle, the semantics we want is called opaque, so "opaque" is ok for me. 

Opaque has meaning only in the JMM (not for the general public)
and in that document the term atomic is also more correct.

> Otherwise, the idea is that you can not cut the loads/stores, so "indivisible" is also ok.

The JVMS uses “indivisible” (see above) to amplify the term “atomic”,
but the primary term is “atomic”.

— John