[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest