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

Nathan and Ila Reynolds nathanila at gmail.com
Thu May 25 09:59:59 EDT 2017


 > 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



More information about the Concurrency-interest mailing list