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

Hans Boehm boehm at acm.org
Wed May 31 19:33:51 EDT 2017

In C++, memory_order_seq_cst as the failure ordering for CAS means it has
volatile load semantics, since there is no store. See 29.3.

A fair fraction of code I've seen, though certainly not the majority, does
not retry CAS on failure. (Admittedly this is usually C++ code.) Often the
failure case is still rare, but that's not always the case. For example,
the code may be looping over a small array trying to find and replace a
non-null array entry. Or the programmer may be trying to set a bit and have
the first setter do some other work. (I don't know whether a plain exchange
would be better; it probably depends on cache line dirtying behavior.)

"compareAndSet and all other read-and-update operations such as
getAndIncrement have the memory effects of both reading and writing
volatile variables." strikes me as sufficiently unclear that it's not
obvious to me we have to do anything. I would probably not have read that
as implying a write for failing CAS.

On Wed, May 31, 2017 at 5:06 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 05/31/2017 07:03 AM, Doug Lea wrote:
> >>
> >> C++ clearly specifies "CAS classic". There is no way to specify
> >> release semantics for a failed CAS, since there is no write.
> >
> > The current C++ spec, sec 29.2 includes versions that do so,
> Except that memory_order_release is specifically disallowed.
> Not that it matters, since the question at hand is about
> volatile/seq_cst.
> -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/20170531/2564fea3/attachment.html>

More information about the Concurrency-interest mailing list