[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
peter.levart at gmail.com
Thu Nov 27 07:48:33 UTC 2014
On 11/27/2014 04:00 AM, David Holmes 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.
...or another acquire/release region?
> 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 . 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
>>  (acting like a monitor exit). Is that contrary to C++ release
>> fences where ordering is restricted both to prior and succeeding
>> accesses? 
>>> So what about the following?
>>> a = r1; // Cannot move below the fence
>>> 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
More information about the core-libs-dev