----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 15 Janvier 2020 02:18:07 > Objet: Re: atomicity for value types
> On Jan 14, 2020, at 4:52 PM, Remi Forax <fo...@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. I'm 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”. > Do you agree that the semantics we want for an inline type that is non teareable and the semantics we want for a value with locked operations (locked like in LADD) are different ? I've chosen "indivisible" because is the latin equivalent of atomic (which comes from the greak leanguage), but that's not the point, the point is that we need two terms given that there are two semantics. Actually the JDK (package java.util.concurrent.atomic) and the JVMS/JLS disagree on what atomic means, this should be fixed too. But it's a collateral problem. Furthermore, at some point in the future, we will want to propose an inline generics that provides locked operations on any values, the natural name for this inline class is "Atomic", an Atomic<long> being the unmutable, zero cost equivalent of an AtomicLong. This will muddy the water even more. > — John Rémi
