I see time to time comments in the jvm sources referencing membars and fences.
Would you say that they are used interchangeably ? Having the same meaning but
for different CPU arch.
Sent from my iPhone
> On Nov 25, 2014, at 6:04 AM, Paul Sandoz <paul.san...@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.
>
> 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?
>
> Paul.
>
> [1] In orderAccess.hpp
> // Execution by a processor of release makes the effect of all memory
> // accesses issued by it previous to the release visible to all
> // processors *before* the release completes. The effect of subsequent
> // memory accesses issued by it *may* be made visible *before* the
> // release. I.e., subsequent memory accesses may float above the
> // release, but prior ones may not float below it.
>
> [2] In memnode.hpp
> // "Release" - no earlier ref can move after (but later refs can move
> // up, like a speculative pipelined cache-hitting Load). Requires
> // multi-cpu visibility. Inserted independent of any store, as required
> // for intrinsic sun.misc.Unsafe.storeFence().
> class StoreFenceNode: public MemBarNode {
> public:
> StoreFenceNode(Compile* C, int alias_idx, Node* precedent)
> : MemBarNode(C, alias_idx, precedent) {}
> virtual int Opcode() const;
> };
>
> [3]
> http://preshing.com/20131125/acquire-and-release-fences-dont-work-the-way-youd-expect/
>
>> On Nov 25, 2014, at 1:47 AM, Martin Buchholz <marti...@google.com> wrote:
>>
>> OK, I worked in some wording for comparison with volatiles.
>> I believe you when you say that the semantics of the corresponding C++
>> fences are slightly different, but it's rather subtle - can we say
>> anything more than "closely related to"?
>>
>> On Mon, Nov 24, 2014 at 1:29 PM, Aleksey Shipilev
>> <aleksey.shipi...@oracle.com> wrote:
>>> Hi Martin,
>>>
>>>> On 11/24/2014 11:56 PM, Martin Buchholz wrote:
>>>> Review carefully - I am trying to learn about fences by explaining them!
>>>> I have borrowed some wording from my reviewers!
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8065804
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/
>>>
>>> I think "implies the effect of C++11" is too strong wording. "related"
>>> might be more appropriate.
>>>
>>> See also comments here for connection with "volatiles":
>>> https://bugs.openjdk.java.net/browse/JDK-8038978
>>>
>>> Take note the Hans' correction that fences generally imply more than
>>> volatile load/store, but since you are listing the related things in the
>>> docs, I think the "native" Java example is good to have.
>>>
>>> -Aleksey.
>> _______________________________________________
>> Concurrency-interest mailing list
>> concurrency-inter...@cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> concurrency-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
