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

[Alexander Terekhov]

> memory_order_release meaningful, but somewhat different from the
non-fence

it would be nice to have release fence with an artificial dependency
to define a set of actually release stores and not constraining other
subsequent stores (and the order of release stores with respect to
each other), e.g.:

// set multiple flags each indicating 'release' without imposing
// ordering on 'release' stores respect to each other and not
// constraining other subsequent stores

.
.
.

if (atomic_thread_fence(memory_order_release)) {

  flag1.store(READY, memory_order_relaxed);
  flag2.store(READY, memory_order_relaxed);

}

regards,
alexander.

Hans Boehm <boehm at acm.org>@cs.oswego.edu on 29.11.2014 05:56:04

Sent by:	concurrency-interest-bounces at cs.oswego.edu


To:	Peter Levart <peter.levart at gmail.com>
cc:	Vladimir Kozlov <vladimir.kozlov at oracle.com>, concurrency-interest
       <concurrency-interest at cs.oswego.edu>, Martin Buchholz
       <martinrb at google.com>, core-libs-dev
       <core-libs-dev at openjdk.java.net>, dholmes at ieee.org
Subject:	Re: [concurrency-interest] RFR: 8065804: JEP 171:
       Clarifications/corrections for fence intrinsics


I basically agree with David's observation.  However the C++

atomic_thread_fence(memory_order_acquire)

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

      _______________________________________________
      Concurrency-interest mailing list
      Concurrency-interest at cs.oswego.edu
      http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest