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

Alex Otenko oleksandr.otenko at gmail.com
Thu May 25 05:54:28 EDT 2017

More than that, you are replacing a volatile read-and-store with a volatile read, so the ordering with respect to other operations will also suffer.

It is a really bad idea.


> On 24 May 2017, at 22:50, Mike Duigou <openjdk at duigou.org> wrote:
> That's my view of this optimization as well; the writes that occur do change but only in ways that nobody should be able to rely upon. Assuming the proposed change to getAndUpdate seemed reasonable to folks I planned to next suggest:
> replace:
> public final boolean compareAndSet(V expect, V update) {
>   return unsafe.compareAndSwapObject(this, valueOffset, expect, update);
> }
> with:
> public final boolean compareAndSet(V expect, V update) {
>    return expect != update
>       ? unsafe.compareAndSwapObject(this, valueOffset, expect, update)
>       : expect != value ? false : true;
> }
> For both the proposed updateAndGet and compareAndSet the goal is to avoid expensive volatile writes when the value is not actually changing.
> Mike
> On 2017-05-24 12:38, Justin Sampson 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