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

Andrew Dinn adinn at redhat.com
Fri May 26 08:56:21 EDT 2017


On 26/05/17 13:46, Doug Lea wrote:
> On 05/26/2017 04:44 AM, Andrew Haley wrote:
> 
>>> a compareAndSet has the memory semantics of a volatile
>>> write regardless of whether or not the write occurred. 
>> That property of compareAndSet is very ugly, and is a pain to
>> implement. Most of the CAS instructions I know about don't have such
>> a property, and making it work requires either an unconditional full
>> fence after every CAS or a conditional one if it fails.  Either way
>> sucks mightily and is unlikely to be useful except in the most
>> pathological cases.
>>
> 
> 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?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


More information about the Concurrency-interest mailing list