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

Hans Boehm boehm at acm.org
Mon Jun 5 17:16:21 EDT 2017

Strongly agreed. From a practical implementation perspective, establishing
a happens-before ordering from a plain failing store to a CAS would require
a fence, or release semantics, to be associated with plain stores. Or CAS
would have to use some Linux-membarrier() like heavy-weight one sided
barrier construct. I don't see how to make that at all practical.

If your code has a plain store failing a (volatile) CAS, you are in wizard
territory and better know how to deal with the consequences.

On Fri, Jun 2, 2017 at 5:06 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 06/01/2017 11:19 AM, Gil Tene wrote:
> >
> > I think the property is that a failing CAS is strictly after the
> > store that failed it, period. Regardless of whether or not that store
> > was volatile.
> Yes, but if it was a plain store, then this need not convey
> any information about any other access that could have been
> reordered with respect to it. So, even though the read-from
> edge can be deduced, we don't need to say anything about it.
> -Doug
> _______________________________________________
> 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/20170605/334d52d7/attachment.html>

More information about the Concurrency-interest mailing list