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

Hans Boehm boehm at acm.org
Sat May 27 13:53:57 EDT 2017


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.

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.

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.

On Sat, May 27, 2017 at 12:05 AM, Gregg Wonderly <gergg at cox.net> wrote:

> 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
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170527/0d776db4/attachment-0001.html>


More information about the Concurrency-interest mailing list