<div dir="ltr">Dear Erik,<div><br></div><div>See inline.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 20, 2016 at 4:49 AM, Erik Österlund <span dir="ltr"><<a href="mailto:erik.osterlund@oracle.com" target="_blank">erik.osterlund@oracle.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
I believe Kim is referring precisely to the release in the fence
before the compare-and-exchange in that comment you refer to, rather
than the membar Store* after the fence.<br></div></blockquote><div><br></div><div>In this case there is no data, written prior to a successful exchange on _time_stamps, being passed to the reader of _time_stamps, so the fence before the exchange is not needed. In fact, it seems to me that a relaxed atomic cmpxchg (using memory_order_relaxed) is sufficient for the update and a plain read is sufficient to read _time_stamps.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
I would prefer to have explicit memory ordering between the linked
producer and consumer pair, as Kim suggests. This is how the JMM
implements sequential consistency - cooperatively with
release_store_fence and load_acquire pairs on the same data.</div></blockquote><div><br></div><div>Hotspot is a C++ program. Mimicking the JMM in Hospot code is misguided (IMHO). In April, migrating the barriers towards the java model was suggested (<a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019079.html">http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019079.html</a>), but the conclusion was a small move towards C++ 11 barriers (<a href="https://bugs.openjdk.java.net/browse/JDK-8155949">https://bugs.openjdk.java.net/browse/JDK-8155949</a>). It would be great if there could be general consensus about the direction of changes to the memory barriers and their use in Hotspot (cc hotspot-runtime-dev as this was discussed there recently).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">It
might very well be that specific architectures might work fine
without the acquire for the consumer as the producer implementation
itself is strong enough to guarantee sequential consistency, but I
don't see why it would be wise to bet on that if we don't have to,
and it does not cost us anything.<br></div></blockquote><div><br></div><div>I don't undersand you reference to sequential consistency here as the only data being passed between threads is the value stored in the field updated by cmpxchg.</div><div><br></div><div>Carsten</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
Thanks,<br>
/Erik<div><div class="gmail-h5"><br>
<br>
<div>On 2016-09-19 21:36, Carsten Varming
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Dear Kim,
<div><br>
</div>
<div>Reading a volatile field updated by cmpxchg does not need
an acquire operation.</div>
<div><br>
</div>
<div>BTW. The specification in atomic.hpp says cmpxchg provides:
"<fence> compare-and-exchange <membar
StoreLoad|StoreStore>". The release is part of the fence.
Are you suggesting that there is a release after the exchange?</div>
<div><br>
</div>
<div>Carsten</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Sep 19, 2016 at 3:18 PM, Kim
Barrett <span dir="ltr"><<a href="mailto:kim.barrett@oracle.com" target="_blank">kim.barrett@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>> On Sep 19, 2016, at 2:26 PM, Carsten
Varming <<a href="mailto:varming@gmail.com" target="_blank">varming@gmail.com</a>>
wrote:<br>
><br>
> Dear Erik,<br>
><br>
> According to orderAccess.hpp an acquire is supposed
to be paired with a release. It doesn't look like there
is any synchronization on the data written to the time
stamp array, so what exactly is going on?<br>
><br>
> Carsten<br>
<br>
</div>
</div>
_time_stamps gets written with a cmpxchg_ptr (line 63 of
gcTaskThread.cpp), which includes release semantics for the
write; see atomic.hpp.<br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>