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

Nathan and Ila Reynolds nathanila at gmail.com
Fri May 26 11:44:25 EDT 2017


 > I've been through denial and anger and there's no point bargaining.  
I'm going to try to make depression as short as possible...

After depression, are you going to try avoidance?  ;)  I hope you can 
move to acceptance and peace with the outcome.

-Nathan

On 5/26/2017 9:36 AM, Andrew Haley wrote:
> On 26/05/17 16:19, Gil Tene wrote:
>
>> I bellieve that making the hardware perform a store release [or
>> equivalent] to a different location is not sufficient to emulate a
>> volatile write's memory semantics, since it e.g. does not prevent
>> subsequent volatile loads of other fields from floating backwards
>> past the store release point, and then e.g. past prior non-volatile
>> stores to the compareAndSet'ed field.
> I'm not quite sure I understand this.  ARMv8's store release and load
> acquire are sequentially consistent.  So, as far as I can see there is
> no way that a subsequent volatile load could possibly float backwards
> past such a store.
>
>> Basically, there is no StoreLoad ordering [that is required to be]
>> enforced on the hardware by a store release, which makes it
>> insufficient.
> Oh yuck, this is *so* *horrible*, but I guess I'll stop worrying about
> it.  The Java spec is what it is, for whatever reasons.
>
> I've been through denial and anger and there's no point bargaining.
> I'm going to try to make depression as short as possible...
>

-- 
-Nathan



More information about the Concurrency-interest mailing list