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

Alex Otenko oleksandr.otenko at gmail.com
Fri May 26 06:31:25 EDT 2017


Perhaps, I’ve skipped a bit of reasoning here.

    x=1
    y=2
------------     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.

Alex


> 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?
> 
> Alex
> 
>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170526/f35e91ba/attachment-0001.html>


More information about the Concurrency-interest mailing list