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

Andrew Haley aph at redhat.com
Fri May 26 09:35:09 EDT 2017

On 26/05/17 13:56, Andrew Dinn wrote:
> 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?

Just thinking about AArch64, and how to implement such a thing as well
as possible.  We can't do a store release to the variable involved in
the CAS, but perhaps we could do a store release to something local to
the thread.  That would be better than a full fence, which would be
overkill for this purpose.  Unlike x86 we can't do an access outside
the stack.  I'm trying to think of something in memory, probably in
the local cache, that can be clobbered, but nothing comes to mind.
OK, here's a mad idea: we could allocate an extra stack slot in a
method which uses

It's definitely faster to do a branch around a full fence than
unconditionally executing the fence, so that may be the best we can
do, but I cannot tell you how much I hate the idea of putting a branch
in hot-path code.  Still, this is only j.u.c. atomics and not used in
things like synchronized blocks, so perhaps it doesn't much matter.

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the Concurrency-interest mailing list