[concurrency-interest] AtomicReference.updateAndGet() mandatory updating

Gregg Wonderly gergg at cox.net
Sat May 27 03:05:42 EDT 2017


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.

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.

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.

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.  

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.

Gregg

> On May 26, 2017, at 3:44 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 25/05/17 18:15, Gil Tene wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On May 25, 2017, at 3:42 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>>> 
>>>> On 05/25/2017 06:16 AM, Andrew Haley wrote:
>> 
>> While on this subject, was the relative "weakening" of compareAndSet (and other) memory semantics between Java 8 and java 9 discussed elsewhere? 
>> 
>> 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.
> That property of compareAndSet is very ugly, and is a pain to implement.
> Most of the CAS instructions I know about don't have such a property,
> and making it work requires either an unconditional full fence after every
> CAS or a conditional one if it fails.  Either way sucks mightily and
> is unlikely to be useful except in the most pathological cases.
> 
> Besides, how does it ever make sense to synchronize with a store that
> never happened?
> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list