<html>
  <head>
    <meta content="text/html; charset=KOI8-R" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thank you. I reviewed the thread, and now I see it did mention that.
    A pair of load/store with acquire/release semantics was only deemed
    adequate for C++11.<br>
    <br>
    Alex<br>
    <br>
    <div class="moz-cite-prefix">On 24/04/2014 00:15, David Holmes
      wrote:<br>
    </div>
    <blockquote
      cite="mid:NFBBKALFDCPFIDBNKAPCAEOHKFAA.davidcholmes@aapt.net.au"
      type="cite">
      <meta content="text/html; charset=KOI8-R"
        http-equiv="Content-Type">
      <meta name="GENERATOR" content="MSHTML 11.00.9600.17041">
      <style>@font-face {
        font-family: Calibri;
}
@font-face {
        font-family: Tahoma;
}
@font-face {
        font-family: Consolas;
}
@page WordSection1 {size: 612.0pt 792.0pt; margin: 2.0cm 42.5pt 2.0cm 3.0cm; }
P.MsoNormal {
        FONT-SIZE: 12pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; MARGIN: 0cm 0cm 0pt
}
LI.MsoNormal {
        FONT-SIZE: 12pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; MARGIN: 0cm 0cm 0pt
}
DIV.MsoNormal {
        FONT-SIZE: 12pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; MARGIN: 0cm 0cm 0pt
}
A:link {
        TEXT-DECORATION: underline; COLOR: blue; mso-style-priority: 99
}
SPAN.MsoHyperlink {
        TEXT-DECORATION: underline; COLOR: blue; mso-style-priority: 99
}
A:visited {
        TEXT-DECORATION: underline; COLOR: purple; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
        TEXT-DECORATION: underline; COLOR: purple; mso-style-priority: 99
}
PRE {
        FONT-SIZE: 10pt; FONT-FAMILY: "Courier New"; COLOR: black; MARGIN: 0cm 0cm 0pt; mso-style-priority: 99; mso-style-link: "๓ิมฮฤมาิฮูส HTML ๚ฮมห"
}
P.MsoAcetate {
        FONT-SIZE: 8pt; FONT-FAMILY: "Tahoma","sans-serif"; COLOR: black; MARGIN: 0cm 0cm 0pt; mso-style-priority: 99; mso-style-link: "๔ลหำิ ืูฮฯำหษ ๚ฮมห"
}
LI.MsoAcetate {
        FONT-SIZE: 8pt; FONT-FAMILY: "Tahoma","sans-serif"; COLOR: black; MARGIN: 0cm 0cm 0pt; mso-style-priority: 99; mso-style-link: "๔ลหำิ ืูฮฯำหษ ๚ฮมห"
}
DIV.MsoAcetate {
        FONT-SIZE: 8pt; FONT-FAMILY: "Tahoma","sans-serif"; COLOR: black; MARGIN: 0cm 0cm 0pt; mso-style-priority: 99; mso-style-link: "๔ลหำิ ืูฮฯำหษ ๚ฮมห"
}
SPAN.HTML {
        FONT-FAMILY: Consolas; COLOR: black; mso-style-priority: 99; mso-style-link: "๓ิมฮฤมาิฮูส HTML"; mso-style-name: "๓ิมฮฤมาิฮูส HTML ๚ฮมห"
}
SPAN.EmailStyle19 {
        FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d; mso-style-type: personal-reply
}
SPAN.a {
        FONT-FAMILY: "Tahoma","sans-serif"; COLOR: black; mso-style-priority: 99; mso-style-link: "๔ลหำิ ืูฮฯำหษ"; mso-style-name: "๔ลหำิ ืูฮฯำหษ ๚ฮมห"
}
.MsoChpDefault {
        FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.WordSection1 {
        page: WordSection1
}
</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div><span class="798391323-23042014"><font color="#0000ff"
            face="Arial" size="2">The discussion of CAS being like a
            "volatile load plus volatile store" did expose that that
            description is inadequate to fully convey the required
            ordering constraints. The actual implementations in the
            Oracle JDK do not allow external accesses to leak into the
            atomic region.</font></span></div>
      <div><span class="798391323-23042014"></span>š</div>
      <div><span class="798391323-23042014"><font color="#0000ff"
            face="Arial" size="2">David</font></span></div>
      <blockquote style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px;
        BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px" dir="ltr">
        <div class="OutlookMessageHeader" dir="ltr" align="left"><font
            face="Tahoma" size="2">-----Original Message-----<br>
            <b>From:</b> <a class="moz-txt-link-abbreviated" href="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</a>
            [<a class="moz-txt-link-freetext" href="mailto:concurrency-interest-bounces@cs.oswego.edu">mailto:concurrency-interest-bounces@cs.oswego.edu</a>]<b>On
              Behalf Of </b>Roman Elizarov<br>
            <b>Sent:</b> Thursday, 24 April 2014 5:58 AM<br>
            <b>To:</b> Oleksandr Otenko<br>
            <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a><br>
            <b>Subject:</b> Re: [concurrency-interest] Stricter read
            ordering<br>
            <br>
          </font></div>
        <div class="WordSection1">
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US">You are right. You cannot
              just split CAS into load and store this way. Actually, if
              you analyze required barriers for write path in the same
              way as I did for read path (remember, that writer has to
              have StoreStore barrier before version write and
              subsequent non-volatile writes), you see that you need to
              insert volatile read _<i>after</i>_ the version.write() in
              the write path, so it becomes:<o:p></o:p></span></p>
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US"><o:p>š</o:p></span></p>
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US">Writer does (in PO):
              version.volatileWrite();š {StoreLoad emitted};
              something.volatileRead(); {LoadStore emitted} x.write();
              y.write(); {StoreStore emitted}; version.write();<o:p></o:p></span></p>
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US"><o:p>š</o:p></span></p>
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US">This effectively gives you
              StoreStore barrier between version write and a first
              non-volatile write of protected data state. Ordering those
              two volatile operations at the beginning of write path the
              other way around, as in your example below, does not
              provide the necessary barrier to guarantee correctness of
              this idiom.<o:p></o:p></span></p>
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US"><o:p>š</o:p></span></p>
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US">CAS has to do both volatile
              load and store in atomic and indivisible way, so that you
              cannot reorder subsequent normal write into the “middle
              of” CAS. This is not explicitly stated in the CAS spec as
              I can see (the wording about “atomic” behavior of CAS and
              about its load/store semantics are rather far apart, so it
              is debatable), but this is the property of CAS that Java
              8’s implementation of StampedLock relies upon, too. <o:p></o:p></span></p>
          <p class="MsoNormal"><span style="FONT-SIZE: 11pt;
              FONT-FAMILY: "Calibri","sans-serif";
              COLOR: #1f497d" lang="EN-US"><o:p>š</o:p></span></p>
          <div>
            <div style="BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT:
              medium none; BORDER-BOTTOM: medium none; PADDING-BOTTOM:
              0cm; PADDING-TOP: 3pt; PADDING-LEFT: 0cm; BORDER-LEFT:
              medium none; PADDING-RIGHT: 0cm">
              <p class="MsoNormal"><b><span style="FONT-SIZE: 10pt;
                    FONT-FAMILY:
                    "Tahoma","sans-serif"; COLOR:
                    windowtext">From:</span></b><span style="FONT-SIZE:
                  10pt; FONT-FAMILY:
                  "Tahoma","sans-serif"; COLOR:
                  windowtext">
                  <a class="moz-txt-link-abbreviated" href="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</a>
                  [<a class="moz-txt-link-freetext" href="mailto:concurrency-interest-bounces@cs.oswego.edu">mailto:concurrency-interest-bounces@cs.oswego.edu</a>] <b>On
                    Behalf Of </b>Oleksandr Otenko<br>
                  <b>Sent:</b> Wednesday, April 23, 2014 11:12 PM<br>
                  <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a><br>
                  <b>Subject:</b> Re: [concurrency-interest] Stricter
                  read ordering<o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p>š</o:p></p>
          <p class="MsoNormal" style="MARGIN-BOTTOM: 12pt">No. If CAS is
            implemented as a volatile load followed by a volatile store,
            the effect I describe is possible. There is no need for a
            weaker implementation for CAS.<br>
            <br>
            Watch:<br>
            <br>
            replace version.compareAndSet with get and set:<br>
            <br>
            v0=version.get();<br>
            version.set(v0 | WRITE);<br>
            this.x=x; // normal write can go ahead of the volatile
            write, as per the cookbook<br>
            <br>
            Or, in JMM terms, there is no edge enforcing this.x=x by the
            writer to appear strictly after x=this.x by the reader.<br>
            <br>
            Alex<o:p></o:p></p>
          <div>
            <p class="MsoNormal">On 23/04/2014 19:34, Roman Elizarov
              wrote:<o:p></o:p></p>
          </div>
          <blockquote style="MARGIN-BOTTOM: 5pt; MARGIN-TOP: 5pt">
            <div>
              <p class="MsoNormal">There was no light in that
                discussion. CAS is currently spec'd as volatile load and
                volatile store. šPeriod. If someone implements CAS on
                ARM with weaker guarantees that violate this spec, then
                StampedLock in Java 8 solution also becomes broken for
                the same reason you've outlined below.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal" style="MARGIN-BOTTOM: 12pt"><br>
                On 23 มะา. 2014 ว., at 21:42, "Oleksandr Otenko" <<a
                  moz-do-not-send="true"
                  href="mailto:oleksandr.otenko@oracle.com">oleksandr.otenko@oracle.com</a>>
                wrote:<o:p></o:p></p>
            </div>
            <blockquote style="MARGIN-BOTTOM: 5pt; MARGIN-TOP: 5pt">
              <div>
                <p class="MsoNormal">In light of the recent discussion
                  of the semantics of CAS, this solution is not correct.<br>
                  <br>
                  The outcome of that discussion is that the atomicity
                  of CAS is only guaranteed with respect to the variable
                  being CASed. This does not matter on x86, but on ARM,
                  as I understand, the CAS will be implemented as two
                  instructions that only preclude concurrent stores to
                  the variable being CASed - which does not preclude
                  reordering the normal stores following CAS with the
                  "volatile store" part of CAS.<br>
                  <br>
                  So, here:<br>
                  <br>
                  <br>
                  <o:p></o:p></p>
                <pre>ššššššš version.compareAndSet(v0, v0 | WRITE); // always succeeds in single-writer case, ensures proper HB edges for JMM<o:p></o:p></pre>
                <pre>ššššššš // then write protected data (non-volatile writes)<o:p></o:p></pre>
                <pre>ššššššš this.x = x;<o:p></o:p></pre>
                <pre>ššššššš this.y = y;<o:p></o:p></pre>
                <p class="MsoNormal" style="MARGIN-BOTTOM: 12pt">this.x=x;
                  may be observed before compareAndSet completes.<br>
                  <br>
                  The correct solution should produce:<br>
                  <br>
                  writer:<br>
                  vwrite(v,v+1)<br>
                  <b>vread(s,_)<br>
                  </b>write(x,_)<br>
                  write(y,_)<br>
                  vwrite(v,v+1)<br>
                  <br>
                  reader:<br>
                  vread(v,_)<br>
                  read(x,_)<br>
                  read(y,_)<br>
                  <b>vwrite(s,_)<br>
                  </b>vread(v,_)<br>
                  <br>
                  For example:<br>
                  <br>
                  writer:<br>
                  // synchronized<br>
                  long next = this.version;<br>
                  this.version=next+1; // odd version means mutation
                  underway<br>
                  long tmp=static_volatile_dummy;<br>
                  this.x=x;<br>
                  this.y=y;<br>
                  this.version=next+2; // even version means immutable<br>
                  <br>
                  reader:<br>
                  long v;<br>
                  do{<br>
                  š while((v=this.version) &1 != 0); // wait for
                  version to become even<br>
                  š x=this.x;<br>
                  š y=this.y;<br>
                  š static_volatile_dummy=v;<br>
                  }while(this.version != v); // check the version didn't
                  change<br>
                  <br>
                  <br>
                  Proof:<br>
                  <br>
                  It is not necessary to consider all possible
                  reorderings individually. It is sufficient to consider
                  relative ordering of volatile reads and writes.<br>
                  <br>
                  All writers ensure exclusive access to this.x and
                  this.y, so we only need to consider one writer
                  performing modifications in a loop.<br>
                  <br>
                  If volatile read of static_volatile_dummy appears
                  after a volatile write of static_volatile_dummy in
                  synchronization order, the former synchronizes-with
                  the latter, and the normal reads of this.x and this.y
                  by the reader happen-before the normal writes of those
                  variables by the writer (transitive closure of program
                  orders). So, the readers never see normal writes of
                  those writers.<br>
                  <br>
                  Now consider the writers whose read of
                  static_volatile_dummy does not synchronize-with the
                  writes. The reader may temporarily observe some
                  values, but will only terminate the loop after
                  observing the values of this.x and this.y whose write
                  appear before the volatile write of a even version:
                  the first loop ensures we only look at writes
                  preceding a write of a even version, the condition of
                  the outer loop ensures no other volatile writes to
                  version appear in synchronization order. This means
                  that the first loop synchronizes-with the last write
                  of a even version, hence, through transitive closure
                  of program orders the normal writes of this.x and
                  this.y happen-before the normal reads. The outer
                  condition ensures that since no other volatile writes
                  of version appear in synchronization order, the
                  volatile read of static_volatile_dummy after all such
                  writes will synchronize-with the volatile write of
                  static_volatile_dummy of the reader (and their normal
                  writes won't be observed, as per the proof in the
                  previous paragraph).<br>
                  <br>
                  <br>
                  This concludes the proof that the reader always
                  observes the consistent view of this.x and this.y.<br>
                  <br>
                  <br>
                  <br>
                  Alex<br>
                  <br>
                  <o:p></o:p></p>
                <div>
                  <p class="MsoNormal">On 23/04/2014 15:16, Roman
                    Elizarov wrote:<o:p></o:p></p>
                </div>
                <blockquote style="MARGIN-BOTTOM: 5pt; MARGIN-TOP: 5pt">
                  <pre>The original problem itself is solvable, albeit with a different algorithm. It's funny, that we've discussed the same problem today internally and then I see this thread on concurrency-interest list. <o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>Let me state the problem first. There is a multi-word state that we have to read and write in non-volatile way (if reads and writes of our state can be made volatile, then solution is trivial and is not of a much interest). We need to implement single-writer multi-reader atomic snapshot of this multi-word state with the primitives described in and under the constraints of the Java Memory Model (think Java 5+). The read does not have to be lock-free. It just needs to detect that snapshot being read is not consistent. In original question author was Ok for reader to spin in case of the read/write conflict, but we actually have a different problem where it is Ok for reader to abandon the read attempt altogether. The key is to detect this conflict or to return an atomic snapshot of the protected state if there is no read/write conflict.<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>So, here is a solution. It can be proven to work on current version of JMM (starting Java 5 and later) in the JMM's model, by analyzing possible executions and their corresponding SO, SW, and HB relations. It requires just one extra int of state (instead of two), but this int needs to be CAS-ed both on read and on write to ensure proper happens-before edges and to guarantee the consistent read of non-volatile state. The proof of this algorithm's correctness is left as an exercise for the reader. It will not scale, though, if there are many concurrent readers, because of the CAS in read path. <o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>class VersionedData {<o:p></o:p></pre>
                  <pre>ššš // bit that we'll use to indicate that the state is being written to<o:p></o:p></pre>
                  <pre>ššš private static final int WRITE = 1 << 31;<o:p></o:p></pre>
                  <pre>ššš // we need to CAS version (in practise we'll do it via Unsafe to avoid extra object)<o:p></o:p></pre>
                  <pre>ššš private final AtomicInteger version = new AtomicInteger();<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>ššš // this is the data I protect, in reality there is much more protected state<o:p></o:p></pre>
                  <pre>ššš private int x, y;<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>ššš public synchronized void update(int x, int y) {<o:p></o:p></pre>
                  <pre>ššššššš // I guarantee single writers to this method,<o:p></o:p></pre>
                  <pre>ššššššš // illustrated with 'synchronized' in this simplification<o:p></o:p></pre>
                  <pre>ššššššš // first use CAS to mark version as being written to<o:p></o:p></pre>
                  <pre>ššššššš int v0 = version.get(); // can be non-volatile read, but then the following CAS can fail and needs to retry<o:p></o:p></pre>
                  <pre>ššššššš version.compareAndSet(v0, v0 | WRITE); // always succeeds in single-writer case, ensures proper HB edges for JMM<o:p></o:p></pre>
                  <pre>ššššššš // then write protected data (non-volatile writes)<o:p></o:p></pre>
                  <pre>ššššššš this.x = x;<o:p></o:p></pre>
                  <pre>ššššššš this.y = y;<o:p></o:p></pre>
                  <pre>ššššššš // then increment version and reset write bit<o:p></o:p></pre>
                  <pre>ššššššš version.set((v0 + 1) & ~WRITE);<o:p></o:p></pre>
                  <pre>ššš }<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>ššš public DataCarrier read() {<o:p></o:p></pre>
                  <pre>ššššššš // I allow multiple readers, so this method is not synchronized<o:p></o:p></pre>
                  <pre>ššššššš int x, y;<o:p></o:p></pre>
                  <pre> šššššššint v0;<o:p></o:p></pre>
                  <pre>ššššššš do {<o:p></o:p></pre>
                  <pre>ššššššššššš // first read version<o:p></o:p></pre>
                  <pre>ššššššššššš v0 = version.get();<o:p></o:p></pre>
                  <pre>ššššššššššš if ((v0 & WRITE) != 0)<o:p></o:p></pre>
                  <pre>ššššššššššššššš continue; // immediately abort, because write in progress was detected<o:p></o:p></pre>
                  <pre>ššššššššššš // then read protected data<o:p></o:p></pre>
                  <pre>ššššššššššš x = this.x;<o:p></o:p></pre>
                  <pre>ššššššššššš y = this.y;<o:p></o:p></pre>
                  <pre>ššššššššššš // use CAS to check that version is still the same and to ensure proper HB edges for JMM at the same time<o:p></o:p></pre>
                  <pre>ššššššš } while (!version.compareAndSet(v0, v0));<o:p></o:p></pre>
                  <pre>ššššššš return new DataCarrier(x, y);<o:p></o:p></pre>
                  <pre>š šš}<o:p></o:p></pre>
                  <pre>}<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>-----Original Message-----<o:p></o:p></pre>
                  <pre>From: <a moz-do-not-send="true" href="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</a> [<a moz-do-not-send="true" href="mailto:concurrency-interest-bounces@cs.oswego.edu">mailto:concurrency-interest-bounces@cs.oswego.edu</a>] On Behalf Of Aleksey Shipilev<o:p></o:p></pre>
                  <pre>Sent: Wednesday, April 23, 2014 5:36 PM<o:p></o:p></pre>
                  <pre>To: Tobias Lindaaker; <a moz-do-not-send="true" href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a><o:p></o:p></pre>
                  <pre>Subject: Re: [concurrency-interest] Stricter read ordering<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>On 04/23/2014 05:05 PM, Tobias Lindaaker wrote:<o:p></o:p></pre>
                  <blockquote style="MARGIN-BOTTOM: 5pt; MARGIN-TOP:
                    5pt">
                    <pre>Yes, I had a look at StampedLock and Unsafe.loadFence(), and it seems <o:p></o:p></pre>
                    <pre>to do exactly what I want, and if I was fortunate enough to be able to <o:p></o:p></pre>
                    <pre>move to Java 8 I would use it. Unfortunately we are still stuck on <o:p></o:p></pre>
                    <pre>Java 7. We even have customers who are still strongly requesting Java<o:p></o:p></pre>
                    <pre>6 compatibility.<o:p></o:p></pre>
                  </blockquote>
                  <pre>These constraints make the problem unresolvable.<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>You might want to look for pre-JDK8 prototype for StampedLock [1]:<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>šššš * As noted in Boehm's paper (above), sequence validation (mainly<o:p></o:p></pre>
                  <pre>šššš * method validate()) requires stricter ordering rules than apply<o:p></o:p></pre>
                  <pre>šššš * to normal volatile reads (of "state").š In the absence of (but<o:p></o:p></pre>
                  <pre>šššš * continual hope for) explicit JVM support of intrinsics with<o:p></o:p></pre>
                  <pre>šššš * double-sided reordering prohibition, or corresponding fence<o:p></o:p></pre>
                  <pre>šššš * intrinsics, we for now uncomfortably rely on the fact that the<o:p></o:p></pre>
                  <pre>šššš * Unsafe.getXVolatile intrinsic must have this property<o:p></o:p></pre>
                  <pre>šššš * (syntactic volatile reads do not) for internal purposes anyway,<o:p></o:p></pre>
                  <pre>šššš * even though it is not documented.<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>ššš public boolean validate(long stamp) {<o:p></o:p></pre>
                  <pre>ššššššš return (stamp & SBITS) == (U.getLongVolatile(this, STATE) & SBITS);<o:p></o:p></pre>
                  <pre>ššš }<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>But if Unsafe.loadFence() is risky since it is not specified (yet) JMM-wise, and so interactions with other volatile ops and fences is just undocumented... then using Unsafe.getXVolatile is double-risky because the behavioral effect of read ordering is *REALLY* implementation-specific, and you if are using it for read ordering, you are five miles past the gateway to Hell already.<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>Thanks,<o:p></o:p></pre>
                  <pre>-Aleksey.<o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>[1]<o:p></o:p></pre>
                  <pre><a moz-do-not-send="true" href="http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/StampedLock.java?revision=1.1">http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/StampedLock.java?revision=1.1</a><o:p></o:p></pre>
                  <pre>_______________________________________________<o:p></o:p></pre>
                  <pre>Concurrency-interest mailing list<o:p></o:p></pre>
                  <pre><a moz-do-not-send="true" href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><o:p></o:p></pre>
                  <pre><a moz-do-not-send="true" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><o:p></o:p></pre>
                  <pre><o:p>š</o:p></pre>
                  <pre>_______________________________________________<o:p></o:p></pre>
                  <pre>Concurrency-interest mailing list<o:p></o:p></pre>
                  <pre><a moz-do-not-send="true" href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><o:p></o:p></pre>
                  <pre><a moz-do-not-send="true" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><o:p></o:p></pre>
                </blockquote>
                <p class="MsoNormal"><o:p>š</o:p></p>
              </div>
            </blockquote>
            <blockquote style="MARGIN-BOTTOM: 5pt; MARGIN-TOP: 5pt">
              <div>
                <p class="MsoNormal">_______________________________________________<br>
                  Concurrency-interest mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
                  <a moz-do-not-send="true"
                    href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><o:p></o:p></p>
              </div>
            </blockquote>
          </blockquote>
          <p class="MsoNormal"><o:p>š</o:p></p>
        </div>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>