<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Does this include compiler fences?<br>
    <br>
    Alex<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 26/02/2014 03:18, Hans Boehm wrote:<br>
    </div>
    <blockquote
cite="mid:CAPUmR1abSiZqSW+DGg5obOs1G00cdcV6cGcGMOovFmi8bJvCrg@mail.gmail.com"
      type="cite">
      <div dir="ltr">I think that's completely uncontroversial.  ARMv8
        load acquire and store release are believed to suffice for Java
        volatile loads and stores respectively.  Even the fence-less
        implementation used a release store exclusive.  Unless I'm
        missing something, examples like this should be handled
        correctly by all proposed implementations, whether or not fences
        are added.
        <div>
          <br>
        </div>
        <div>As far as I can tell, the only use case that require the
          fences to be added are essentially abuses of CAS as a fence.</div>
        <div><br>
        </div>
        <div>Hans</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">
          On Tue, Feb 25, 2014 at 9:45 AM, Oleksandr Otenko <span
            dir="ltr"><<a moz-do-not-send="true"
              href="mailto:oleksandr.otenko@oracle.com" target="_blank">oleksandr.otenko@oracle.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF"> Not sure what you are
              asking for - a Java or C++ example? (I don't know C++
              semantics)<br>
              <br>
              But emptying a cyclic buffer is a example where CAS must
              behave at least as a volatile store:<br>
              <br>
              long w_pos; // updated in a synchronized block<br>
              AtomicLong r_pos;<br>
              Object [] array;<br>
              ...<br>
              <br>
              long r;<br>
              while ((r = r_pos.get()) != w_pos) {<br>
                Object v = array[(int)(r % array.length)];<br>
                if (r_pos.compareAndSet(r, r+1)) return v;<br>
              }<br>
              <br>
              If r_pos.compareAndSet does not have barriers of a
              volatile store, then volatile loads are hoistable.<br>
              <br>
              Alex<br>
              <br>
              <br>
              <div>On 25/02/2014 16:21, Hans Boehm wrote:<br>
              </div>
              <blockquote type="cite">
                <div dir="ltr">Could someone post a test case that they
                  think should work, but that doesn't work with the
                  acquire/release implementation (without added fences)?
                   Clearly it does not work as a general purpose fence
                  replacement, e.g. when used on an object accessed by
                  only one thread.  But I hope that was not intended.
                   It does seem to me that it does preserve the property
                  that properly synchronized programs are sequentially
                  consistent.
                  <div> <br>
                  </div>
                  <div>It seems to have the same synchronization
                    properties as if all operations on an atomic class
                    were implemented with locks.  This is clearly
                    allowed for C++, and I would have presumed that it's
                    intended to be allowed for j.u.c.</div>
                  <div><br>
                  </div>
                  <div>Definitive answers here would be a lot easier if
                    we had more precise specifications, both for Java
                    and the ARMv8 ISA.</div>
                  <div><br>
                  </div>
                  <div>Hans</div>
                </div>
                <div class="gmail_extra"><br>
                  <br>
                  <div class="gmail_quote"> On Mon, Feb 24, 2014 at 9:13
                    AM, Andrew Haley <span dir="ltr"><<a
                        moz-do-not-send="true"
                        href="mailto:aph@redhat.com" target="_blank">aph@redhat.com</a>></span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      On 02/24/2014 02:47 PM, Oleksandr Otenko wrote:<br>
                      > Hmmm...<br>
                      ><br>
                      > Can someone clarify this issue? I don't know
                      ARM instructions, yet it<br>
                      > seems the discussion contradicts itself.<br>
                      ><br>
                      > This here observation summarizes that "GCC's
                      usage of ....<instruction<br>
                      > sequence> is ok" despite it not being a
                      full barrier, and that the<br>
                      > reordering of memop_A and memop_C before and
                      after CAS respectively, is<br>
                      > allowed.<br>
                      ><br>
                      > Yet further in the discussion Doug mentions
                      it is meant to be a volatile<br>
                      > read+volatile write, which would preclude the
                      reordering of memop_A and<br>
                      > memop_C.<br>
                      ><br>
                      > So, is that reordering allowed or not?<br>
                      <br>
                      Not by Java, no.  A ldx.acq ... stx.rel is not
                      enough for Java's<br>
                      compareAndSwap.  We are sure about that.<br>
                      <br>
                      However, according to Stephan Diestelhorst it *is*
                      enough for the<br>
                      implementation of the C++11 atomics, and the
                      notion of sequential<br>
                      consistency of atomics.<br>
                      <br>
                      I do not know what Stephan bases that claim on.<br>
                      <br>
                      Andrew.<br>
                      _______________________________________________<br>
                      Concurrency-interest mailing list<br>
                      <a moz-do-not-send="true"
                        href="mailto:Concurrency-interest@cs.oswego.edu"
                        target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                      <a moz-do-not-send="true"
                        href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
                        target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </blockquote>
              <br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>