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

[Peter Levart]

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?

Regards, Peter

>
> 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