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

Alex Otenko oleksandr.otenko at gmail.com
Thu May 25 18:46:45 EDT 2017


We also need to keep the StoreLoad barrier before the CAS.

While it is not needed when the atomic is used (preemptive read is only a guess; making a wrong guess still keeps the barriers of the atomic), in the “optimized” version preemptive read of the expected value can reorder things.

Alex
 
> On 25 May 2017, at 14:59, Nathan and Ila Reynolds <nathanila at gmail.com> wrote:
> 
> > The best we could so here is replace elided volatile write with a full fence, which would probably not be detectably faster.
> 
> I definitely agree with Alex Otenko's position of keeping the synchronizes-with edge.  I can think of several places in code where removing this edge would cause all sorts of wacky hard-to-reproduce issues.  Doug's suggestion I quoted above seems like a good solution.  From my limited perspective, his suggestion seems to keep the synchronizes-with edge yet avoid the volatile write.  I can assure you that replacing a volatile write with a full fence is definitely faster.  On a highly contended cache line, eliding a volatile write will definite improve scalability. I can think of one place in code where each write to the cache line is very costly in terms of scalability.  I've spent a lot of time optimizing that code to reduce the number of writes to 1 cache line.  Before this optimization, cores would sit at 100% utilization but the internal execution pipelines were stalled waiting for a highly contended cache line.
> 
> -Nathan
> 
> On 5/25/2017 4:39 AM, Doug Lea wrote:
>> On 05/25/2017 06:16 AM, Andrew Haley wrote:
>>> On 25/05/17 09:16, Gil Tene wrote:
>>>>> On May 25, 2017, at 12:35 AM, Alex Otenko
>>>>> <oleksandr.otenko at gmail.com> wrote:
>>>>> 
>>>>> This is a bad idea.
>>>>> 
>>>>> Now there is no guarantee that the synchronizes-with edge
>>>>> exists.
>>>> The current Java 9 specification (in the JavaDoc) of
>>>> AtomicReference.updateAndGet() doesn't say there is such an edge
>>>> (the Java 8 one did, but the current Java 9 one doesn't).
>>> Ah, I see:
>>> 
>>> "compareAndSet and all other read-and-update operations such as
>>> getAndIncrement have the memory effects of both reading and writing
>>> volatile variables. " seems to have gone.
>> Thanks for pointing this out!
>> The "...and all other read-and-update operations" clause
>> inadvertently disappeared while meshing j.u.c.atomic specs
>> with jdk9 VarHandles
>> (http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html)
>> 
>> The updateAndGet method is not a part of VarHandles, so is no longer
>> covered by any existing statement. We will need to somehow do so.
>> 
>> And so, Mike: Some existing code might rely on this, so the best we
>> could so here is replace elided volatile-write with a fullFence,
>> which would probably not be detectably faster.
>> 
>> -Doug
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> -- 
> -Nathan
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list