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

Alex Otenko oleksandr.otenko at gmail.com
Fri May 26 05:09:18 EDT 2017

Yes, I know what hardware does, but it is not a problem to model it as a “always store”. What is “stored" on CAS fail? The value that is already there.

The key point is still about guaranteeing mutual exclusion (false indicates the existence of a concurrent mutator).

If you don’t want to guarantee mutual exclusion (false does not indicate existence of a concurrent mutator), then how is it different from weakCompareAndSet (can fail spuriously)? What are the reasons to not use weakCompareAndSet?


> On 26 May 2017, at 10:03, Andrew Haley <aph at redhat.com> wrote:
> On 26/05/17 09:52, Alex Otenko wrote:
>> A store is not never happened, it is a store of the same value that is already there
> This part of the discussion is about a failing CAS: the store does not take
> place.
> -- 
> 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