[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
boehm at acm.org
Sat Nov 29 04:56:04 UTC 2014
I basically agree with David's observation. However the C++
actually has somewhat different semantics from load(memory_order_acquire).
It basically ensures that prior atomic loads L are not reordered with later
(i.e. following the fence in program order) loads and stores, making it
something like a LoadLoad|LoadStore fence. Thus the fence orders two sets
of operations where the acquire load orders a single operation with respect
to a set. This makes the fence versions of memory_order_acquire and
memory_order_release meaningful, but somewhat different from the non-fence
versions. The terminology is probably not great, but that seems to be the
most common usage now.
On Wed, Nov 26, 2014 at 11:48 PM, Peter Levart <peter.levart at gmail.com>
> 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
>> anything to move into a region bounded by acquire() and release(), then
>> 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
>> 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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the core-libs-dev