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

Doug Lea dl at cs.oswego.edu
Fri May 26 09:56:03 EDT 2017


On 05/26/2017 09:35 AM, Andrew Haley wrote:
> On 26/05/17 13:56, Andrew Dinn wrote:

>>> Initially (in Java5) requiring it has led to some questionable reliance.
>>>  So we cannot change it. But there's not much motivation to do so anyway:
>>> As implied by Nathan Reynolds, encountering some (local) fence overhead
>>> on CAS failure typically reduces contention and may improve throughput.
>>
>> It would be useful to know if that reduction in contention is specific
>> to, say, x86 hardware or also occurs on weak memory architectures like
>> AArch64 or ppc. Perhaps Nathan could clarify that?

The main issues are not tightly bound to architecture.
In the vast majority of cases, the response to CAS failure is
some sort of retry (although perhaps with some intermediate
processing). The fence here plays a similar role to
Thread.onSpinWait. And in fact, on ARM, is likely to be
exactly the same implementation as onSpinWait.

As Alex mentioned, in the uncommon cases where this
is a performance issue, people can use one of the weak CAS
variants.

> 
> Just thinking about AArch64, and how to implement such a thing as well
> as possible. 

"As well as possible" may be just to unconditionally issue fence,
at least for plain CAS; maybe differently for the variants.

-Doug




More information about the Concurrency-interest mailing list