[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

[David Holmes]

Can I make an observation about acquire() and release() - to me they are
meaningless when considered in isolation. Given their definitions they allow
anything to move into a region bounded by acquire() and release(), then you
can effectively move the whole program into the region and thus the
acquire() and release() do not constrain any reorderings. acquire() and
release() only make sense when their own movement is constrained with
respect to something else - such as lock acquisition/release, or when
combined with specific load/store actions.

David

Martin Buchholz writes:
>
> On Tue, Nov 25, 2014 at 6:04 AM, Paul Sandoz
> <paul.sandoz at oracle.com> wrote:
> > Hi Martin,
> >
> > Thanks for looking into this.
> >
> > 1141      * Currently hotspot's implementation of a Java
> language-level volatile
> > 1142      * store has the same effect as a storeFence followed
> by a relaxed store,
> > 1143      * although that may be a little stronger than needed.
> >
> > IIUC to emulate hotpot's volatile store you will need to say
> that a fullFence immediately follows the relaxed store.
>
> Right - I've been groking that.
>
> > The bit that always confuses me about release and acquire is
> ordering is restricted to one direction, as talked about in
> orderAccess.hpp [1]. So for a release, accesses prior to the
> release cannot move below it, but accesses succeeding the release
> can move above it. And that seems to apply to Unsafe.storeFence
> [2] (acting like a monitor exit). Is that contrary to C++ release
> fences where ordering is restricted both to prior and succeeding
> accesses? [3]
> >
> > So what about the following?
> >
> >   a = r1; // Cannot move below the fence
> >   Unsafe.storeFence();
> >   b = r2; // Can move above the fence?
>
> I think the hotspot docs need to be more precise about when they're
> talking about movement of stores and when about loads.
>
> > // release.  I.e., subsequent memory accesses may float above the
> > // release, but prior ones may not float below it.
>
> As I've said elsewhere, the above makes no sense without restricting
> the type of access.
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest