[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
oleksandr.otenko at gmail.com
Fri May 26 06:31:25 EDT 2017
Perhaps, I’ve skipped a bit of reasoning here.
------------ other threads are possibly doing:
CAS CAS volatile store
------------ ------------ --------------
False True False True |
| | | | |
A B ... B B
Broad guarantee is that no more than one thread will follow branch B. The strong version of CAS also guarantees that at least one thread will follow branch B (so False is a constructive proof of existence of a mutator).
Java 8 CAS is always a store. This means that x=1 and y=2 are both visible to both A and B, irrespective of the outcome. This means that I can move responsibility for observing and processing the x=1 and y=2 between A and B.
If we do not guarantee a store when CAS fails, then I cannot move responsibility for observing and processing the x=1 and y=2 from A to B. In this respect CAS becomes similar to, if not the same as weakCompareAndSet - False no longer guarantees mutually exclusive processing of x=1 and y=2, and no longer needs to be a constructive proof of existence of a mutator.
> On 26 May 2017, at 10:09, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
> 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
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest