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

Gil Tene gil at azul.com
Thu Jun 1 13:07:52 EDT 2017


> On Jun 1, 2017, at 9:58 AM, Gil Tene <gil at azul.com> wrote:
> 
> 
>> On Jun 1, 2017, at 9:53 AM, Andrew Haley <aph at redhat.com> wrote:
>> 
>> On 01/06/17 16:19, Gil Tene wrote:
>>> I think the property is that a failing CAS is strictly after the store that failed it, period. Regardless of whether or not that store was volatile.
>> 
>> How is that even possible?  The store that fails a CAS can propagate
>> to different threads later: it's not part of the total order.  Perhaps
>> I'm missing something.
> 
> It can. But the CAS failed *because* of that store [it is not allowed to spuriously fail], so the CAS is after that store. And things that are after the CAS are therefore also after that store.
> 

BTW, I think this is a way to highlight the meaning of an implied volatile write even on failure:

*If* a failing CAS behaves like it had done a volatile store to the field (of the value that it observed and caused the failure, regardless of whether that value was stored there volatile-ly or not before), then that gives the original store that failed the CAS the impact of a Volatile store (at the CAS point) to other threads, even if that original store was Plain. Other threads that do things that happen-after the CAS will have those same things happen-after the failing store. 

However, if the failing CAS does not carry the behavior of a volatile store on failure, and the store that failed the CAS was Plain, other threads may do things that happen-after the failing CAS, but which may not observe the failing store.

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