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

Alex Otenko oleksandr.otenko at gmail.com
Thu May 25 04:23:28 EDT 2017

How quickly you arrived at “no algorithm whatsoever”! :-)


Under assumption that there are infinitely many volatile reads of y, the return from compareAndSet is a witness that there exists a read in the future that synchronizes-with this invocation of compareAndSet.

You cannot argue that sometimes you can skip the volatile store semantics on what would be a successful compareAndSet - because then the stores preceding compareAndSet are not guaranteed to be visible - ever. This optimization is a platform-specific decision.

You can argue about what happens if compareAndSet fails. My take is it should still have volatile store semantics - ie should be equivalent to the store of the value that is already there, so it appears unmodified, but synchronizes-with edges can be established.


> On 24 May 2017, at 20:38, Justin Sampson <jsampson at guidewire.com> wrote:
> Andrew Haley wrote:
>> Mike Duigou wrote:
>>> I find that I write a lot of update functions which only occasionally
>>> change the value. For these cases I wonder if it would be reasonable to
>>> skip the update if the value of next is unchanged from previous.
>> I don't think so, because the update has the effect of a volatile
>> write. If you skip the update you lose the happens-before ordering
>> of that write.
> That's strictly true (the memory barriers come out different), but no
> algorithm could actually rely on the difference. The reading thread can't
> tell if it's reading after the write (and therefore can depend on the
> happens-before) or reading before the write (and therefore cannot), since
> it sees the same value in either case.
> This kind of optimization is already done in some places in the JDK, such
> as AtomicStampedReference and AtomicMarkableReference, both of which skip
> the write if the current value is already equal to the new value in set(),
> compareAndSet(), etc.
> Cheers,
> Justin
> _______________________________________________
> 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