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

[David Holmes]

Martin writes:
> On Wed, Nov 26, 2014 at 7:00 PM, David Holmes 
> <davidcholmes at aapt.net.au> wrote:
> > 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, it seems you are agreeing with my argument below.  The
> definitions in the hotspot sources should be fixed, in the same sort
> of way that I'm trying to make the specs for Unsafe loads clearer and
> more precise.

Please see:

https://bugs.openjdk.java.net/browse/JDK-7143664

Though I'm not sure my ramblings there reflect my current thoughts on all this. I really think acquire/release are too confusingly used to be useful - by which I mean that the names do not reflect their actions so you will always have to remember/look-up exactly what *release* and *acquire* mean in that context, and hence talking about "acquire semantics" and "release semantics" becomes meaningless. In contrast the loadload|loadstore etc barriers are completely straight-forward to understand from their names. However it seems they are too strong compared to what recent hardware provides.

Hotspot implementations in orderAccess are confusing - barriers with different semantics have been defined in terms of the other, but the low-level implementations provide a barrier that is stronger than the required semantics, so the high-level APIs are "satisfied" correctly, even if not implemented in a way that makes sense if you reason about what each barrier theoretically allows.

David
 
> > David
> >
> > Martin Buchholz writes:
> >> 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.
>