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

Mike Duigou openjdk at duigou.org
Wed May 24 17:50:50 EDT 2017


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


More information about the Concurrency-interest mailing list