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

Hans Boehm boehm at acm.org
Thu May 25 18:01:22 EDT 2017


IIUC, you're arguing that this transformation is valid only if we know that
the implementation does not indefinitely delay the store to x past the
do-while loop implementing compareAndSet()? E.g. if the compareAndSet
thread subsequently prints something, and then goes into an infinite loop,
I still have a guarantee that a thread that alternately reads x and y will
eventually see x == 1?

I'm inclined to agree with that, though I expect that implementations
violating this assumption are really rare.

On Thu, May 25, 2017 at 1:23 AM, Alex Otenko <oleksandr.otenko at gmail.com>
wrote:

> How quickly you arrived at “no algorithm whatsoever”! :-)
>
> x=1;
> y.compareAndSet(e,v)
>
> Under assumption that there are infinitely many volatile reads of y, the
> return from compareAndSet is a witness that there exists a read in the
> future that synchronizes-with this invocation of compareAndSet.
>
> You cannot argue that sometimes you can skip the volatile store semantics
> on what would be a successful compareAndSet - because then the stores
> preceding compareAndSet are not guaranteed to be visible - ever. This
> optimization is a platform-specific decision.
>
>
> You can argue about what happens if compareAndSet fails. My take is it
> should still have volatile store semantics - ie should be equivalent to the
> store of the value that is already there, so it appears unmodified, but
> synchronizes-with edges can be established.
>
>
> Alex
>
> > On 24 May 2017, at 20:38, Justin Sampson <jsampson at guidewire.com> wrote:
> >
> > Andrew Haley wrote:
> >> Mike Duigou wrote:
> >>> I find that I write a lot of update functions which only occasionally
> >>> change the value. For these cases I wonder if it would be reasonable to
> >>> skip the update if the value of next is unchanged from previous.
> >>
> >> I don't think so, because the update has the effect of a volatile
> >> write. If you skip the update you lose the happens-before ordering
> >> of that write.
> >
> > That's strictly true (the memory barriers come out different), but no
> > algorithm could actually rely on the difference. The reading thread can't
> > tell if it's reading after the write (and therefore can depend on the
> > happens-before) or reading before the write (and therefore cannot), since
> > it sees the same value in either case.
> >
> > This kind of optimization is already done in some places in the JDK, such
> > as AtomicStampedReference and AtomicMarkableReference, both of which skip
> > the write if the current value is already equal to the new value in
> set(),
> > compareAndSet(), etc.
> >
> > Cheers,
> > Justin
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170525/1a5cb4d1/attachment-0001.html>


More information about the Concurrency-interest mailing list