Martin writes: > On Wed, Nov 26, 2014 at 7:00 PM, David Holmes > <davidchol...@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. >
