<div dir="ltr">Could we please get an example (i.e. litmus test) of how the "memory effect of at least one volatile ... write" is visible, and where it's useful? Since some people seem really attached to it, it shouldn't be that hard to generate a litmus test.<div><br></div><div>So far we have a claim that it could affect progress guarantees, i.e. whether prior writes eventually become visible without further synchronization. I kind of, sort of, half-way believe that.<br><div><br></div><div>I haven't been able to make sense out of the subsequent illustration attempts. I really don't think it makes sense to require such weird behavior unless we can at least clearly define exactly what the weird behavior buys us. We really need a concise, or at least precise and understandable, rationale.</div><div><br></div><div>As has been pointed out before, a volatile write W by T1 to x of the same value that was there before is not easily observable. If I read that value in another thread T2, I can't tell which write I'm seeing, and hence hence a failure to see prior T1 writes is OK; I might have not seen the final write to x. Thus I would need to communicate the  fact that T1 completed W without actually looking at x. That seems to involve another synchronization of T1 with T2, which by itself would ensure the visibility of prior writes to T2.</div><div><br></div><div>Thus, aside from possible really obscure progress/liveness issues, I really don't see the difference. I think this requirement, if it is indeed not vacuous and completely ignorable, would lengthen the ARMv8 code sequence for a CAS by at least 2 instructions, and introduce a very obscure divergence from C and C++.</div><div><br></div><div>I'm worried that we're adding something to make RMW operations behave more like fences. They don't, they can't, and they shouldn't.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 1:08 PM, Nathan and Ila Reynolds <span dir="ltr"><<a href="mailto:nathanila@gmail.com" target="_blank">nathanila@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> "The memory effects of a write occur regardless of outcome."<br></span><span class="">
> "This method has memory effects of at least one volatile read and write."<br>
<br></span>
I am not sure what memory effects means.  If this is defined somewhere in the specs, then ignore this since I haven't read JDK 9 specs.<br>
<br>
Does memory effects mean the cache line will be switched into the modified state even if an actual write doesn't occur?  Or does memory effects have to do with ordering of memory operations with respect to the method's operation?<br>
<br>
-Nathan<div class="HOEnZb"><div class="h5"><br>
On 5/26/2017 1:59 PM, Doug Lea wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/26/2017 12:22 PM, Gil Tene wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Actually this is another case where the Java 9 spec needs to be adjusted…<br>
</blockquote>
The pre-jdk9 method for weak CAS is now available in four<br>
flavors: weakCompareAndSetPlain, weakCompareAndSet,<br>
weakCompareAndSetAcquire, weakCompareAndSetRelease.<br>
They have different read/write access modes. The specs reflect this.<br>
The one keeping the name weakCompareAndSet is stronger, the others<br>
weaker than before (this is the only naming scheme that works).<br>
<br>
About those specs... see JBS JDK-8181104<br>
   <a href="https://bugs.openjdk.java.net/browse/JDK-8181104" rel="noreferrer" target="_blank">https://bugs.openjdk.java.<wbr>net/browse/JDK-8181104</a><br>
The plan is for all CAS VarHandle methods to include the sentence<br>
   "The memory effects of a write occur regardless of outcome."<br>
And for j.u.c.atomic methods getAndUpdate, updateAndGet,<br>
getAndAccumulate, accumulateAndGet to include the sentence:<br>
   "This method has memory effects of at least one volatile read and write."<br>
<br>
Which should clear up confusion.<br>
<br>
-Doug<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego<wbr>.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/l<wbr>istinfo/concurrency-interest</a><br>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
-Nathan</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego<wbr>.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/l<wbr>istinfo/concurrency-interest</a><br>
</div></div></blockquote></div><br></div></div></div></div>