In the context of Java, we are already using the term 'atomic', in AtomicInteger, AtomicLong, etc, 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.
As Doug said, for a VarHandle, the semantics we want is called opaque, so "opaque" is ok for me. Otherwise, the idea is that you can not cut the loads/stores, so "indivisible" is also ok. Rémi > De: "John Rose" <john.r.r...@oracle.com> > À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 15 Janvier 2020 01:40:34 > Objet: Re: atomicity for value types > On Dec 18, 2019, at 5:46 PM, John Rose < [ mailto:john.r.r...@oracle.com | > john.r.r...@oracle.com ] > wrote: >> - Define a contextual keyword “alwaysatomic" (working title >> “__AlwaysAtomic”). > I just referred more carefully to the draft JEP on keyword > management [ https://openjdk.java.net/jeps/8223002 | > https://openjdk.java.net/jeps/8223002 ] and > realize that it guides us toward a so-called “hyphenated > contextual keyword” in preference to a “unitary contextual > keyword”. That is, “always-atomic” is more in keeping with > that document than “alwaysatomic”. > I do think this looks more jarring than the unitary keyword: > always-atomic inline class Cursor { … } > But, that’s only because it’s an early hyphenated keyword, > which nobody is eye-trained on yet. If we believe that > hyphenated keywords are the wave of the future, as I do, > then we should embrace it, rather than the old-school > unitary token “alwaysatomic”. > In the prototype I’m using a temporary (unitary contextual) keyword-ato > __AlwaysAtomic, plus a temporary annotation @__alwaysatomic__. > In the JVMs the draft of the corresponding modifier bit looks like this: > ACC_ALWAYSATOMIC 0x0040 Instances of this inline type are never torn.
