<div dir="ltr">I continue to disagree. Most code should not be using racing variable accesses to start with. It's really hard to get such code correct, volatile semantics or not. And surprisingly often it ends up being slower than just using locks. Especially on something like ARM, where lock-based code often requires fewer fences than clever lock-free code.<div><br></div><div>If you ignore that advice, and you know which variable accesses are racing, you should declare them volatile or atomic, because readers of the code will want to know, too. And you're back to sequentially consistent semantics. If you don't know which variable accesses are racing, odds are about 99.9% that your code is broken anyway.</div><div><br></div><div>If just using volatile semantics is still too slow, then you are indeed stuck with reasoning about visibility, and correctness arguments will be a mess, stuff may not compose well, etc. But if you're in that situation, volatile-by-default wouldn't have helped you either.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 27, 2017 at 12:05 AM, Gregg Wonderly <span dir="ltr"><<a href="mailto:gergg@cox.net" target="_blank">gergg@cox.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The “visibility” part of the JMM, since 1.5, has plagued many applications by requiring viral use of synchronization or fences or large scale happens before studies.  This happened because hardware cache line abuse was horribly expensive and so people tried to avoid synchronized after seeing how much faster HashMap and ArrayList were, compared to Hashtable and Vector.   So, people first just avoided synchronized, and lost edges that cause visibility to suddenly be a problem.<br>
<br>
Add to that, the deadly optimization of non-volatile loop control parameters into if() { while(true){} }, and suddenly the recommendation everywhere as “volatile” or “final” on every class variable so that loops would start working again.<br>
<br>
As people learned more and more about how java.util.concurrent worked, and stared at source, and read comments and tried to comprehend things, suddenly Unsafe.XXX was being used in lots of places to try and “fix” problems where “synchronized” was too expensive, but happens before was needed for visibility.<br>
<br>
In the end, I think it was a pretty grave error to not make “volatile” the default and require some annotation to say, I know how to manage the visibility of this variable.<br>
<br>
We are at the point now, that all of these kinds of discussions with disgust and confusion, point to the wrong path having been taken.  There is way too much wiring and way too much of it visible as cross-domain side effects.   Side effects across objects and those which when removed invalidate unrelated software, are exactly the problems we really don’t need.<br>
<span class="HOEnZb"><font color="#888888"><br>
Gregg<br>
</font></span><span class="im HOEnZb"><br>
> On May 26, 2017, at 3:44 AM, Andrew Haley <<a href="mailto:aph@redhat.com">aph@redhat.com</a>> wrote:<br>
><br>
> On 25/05/17 18:15, Gil Tene wrote:<br>
>><br>
>><br>
</span><span class="im HOEnZb">>> Sent from my iPad<br>
>><br>
>>> On May 25, 2017, at 3:42 AM, Doug Lea <<a href="mailto:dl@cs.oswego.edu">dl@cs.oswego.edu</a>> wrote:<br>
>>><br>
>>>> On 05/25/2017 06:16 AM, Andrew Haley wrote:<br>
>><br>
</span><span class="im HOEnZb">>> While on this subject, was the relative "weakening" of compareAndSet (and other) memory semantics between Java 8 and java 9 discussed elsewhere?<br>
>><br>
>> In java 8, a compareAndSet has the memory semantics of a volatile write regardless of whether or not the write occurred. In java 9 it only has a volatile write effect if the write occurs. While the loosening in the non-writing case may allow for additional optimizations, I worry that it may break existing code that could rely on the previous behavior.<br>
</span><span class="im HOEnZb">> That property of compareAndSet is very ugly, and is a pain to implement.<br>
> Most of the CAS instructions I know about don't have such a property,<br>
> and making it work requires either an unconditional full fence after every<br>
> CAS or a conditional one if it fails.  Either way sucks mightily and<br>
> is unlikely to be useful except in the most pathological cases.<br>
><br>
</span><span class="im HOEnZb">> Besides, how does it ever make sense to synchronize with a store that<br>
> never happened?<br>
><br>
</span><span class="im HOEnZb">> --<br>
> Andrew Haley<br>
> Java Platform Lead Engineer<br>
> Red Hat UK Ltd. <<a href="https://www.redhat.com" rel="noreferrer" target="_blank">https://www.redhat.com</a>><br>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> Concurrency-interest mailing list<br>
> <a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.<wbr>oswego.edu</a><br>
> <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/<wbr>listinfo/concurrency-interest</a><br>
<br>
______________________________<wbr>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.<wbr>oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/<wbr>listinfo/concurrency-interest</a><br>
</div></div></blockquote></div><br></div>