[jmm-dev] Specifying VarHandle acquire/release without ill effects

[Hans Boehm]

I think C++'s definitions of acquire/release, as refined by the work by
Mark Batty et al, are in pretty good shape.  But I strongly suspect they
are incompatible with Java's notion of a total synchronization order.  That
order is not very meaningful for acquire/release operations.  Specifying
acquire/release correctly in a Java context does require some work.

On Fri, Jun 17, 2016 at 1:34 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 06/17/2016 11:08 AM, Andrew Haley wrote:
> > On 16/06/16 21:28, Aleksey Shipilev wrote:
> >
> >> The clause about reorderings trips users into believing that
> >> getAcquire and putRelease have fence-like semantics. But in reality,
> >> they are weaker than fences, because optimizers are not obliged to
> >> introduce barriers around the operation to get the needed semantics.
> >
> > I've read this several times now and I still do not understand it.
> > Release and acquire are well-defined terms in the industry,
>
> I dare anyone to produce the consistent industry definition of "acquire"
> and "release" :)
>
> > and I can't think of any great reason to add more words like yours,
> > which seem to make things even more confusing than they were. The
> > wording which is there seems to me to be accurate, at least, as a
> > description of release and acquire.
>
> That might be true if you take the *hardware* definition of
> acquire/releases, where prohibiting reorderings is surely a plausible
> semantics. (There is no telling if CPU vendors will some day describe
> their hardware memory models with abstract rules, like high-level
> languages do)
>
> But the trouble is with allowing software optimizations, as volatile
> example shows. A runtime should be able to elide barriers around
> volatiles, if this elision does not violate JMM. In fact, it is
> trivially doable when optimizers realize they are dealing with
> thread-local volatile ops (e.g. on a non-escaped object, or in
> constructor). This is what my original example shows.
>
> Now, VarHandle's acquire/release can be seen as further _relaxations_ of
> volatile semantics, when you give up sequential consistency for better
> performance. Therefore, the barriers around acquire/releases should also
> be elide-able. Therefore, specifying VarHandle's acquire/release with
> reoderings is odd.
>
> You can certainly specify that acq/rel inhibit reordering, but this way
> we face even a weirder inconsistency. It means that volatiles are *more
> optimizeable* than acq/rel, which defeats the purpose of having acq/rel
> to begin with!
>
> HTHS,
> -Aleksey
>
>