[concurrency-interest] Can a volatile read be reordered before a lazySet?

Thomas Kountis tkountis at gmail.com
Tue Dec 23 21:17:54 EST 2014


David,

AFAIK all the atomic* members that Java provides, pretty much provide the
same guarantees
as the volatile keyword does - which doesn't allow re-orderings on the
compiler side, neither during execution.
If you look behind the covers, the fields that those two wrappers work on,
are marked volatile as well. Also, lazy-set
is using the Unsafe.putOrdered...() which relies on a store-store barrier
and will prevent any instruction re-ordering (as the name suggests).

So, to answer your question, I believe you are safe as far as it concerns
re-orderings on your example.

t.

On Tue, Dec 23, 2014 at 10:50 PM, Dávid Karnok <akarnokd at gmail.com> wrote:
>
> Hello,
>
> Given two atomic values held by an AtomicLong and an AtomicReference, is
> it possible the following two lines may be reordered?
>
> theLong.lazySet(theLong.get() + 1);
> Object o = theRef.get();
>
> On X86, the memory model states that reads may be reordered with older
> writes to different locations, so the algorithm fragment above might be
> broken. For context, this code is part of a single-producer structure wich
> protects the use of theRef value with an ingress/egress counter pair.
>
> I wonder if the same reordering might happen in a classical atomic
> ping-pong example:
>
> ping.lazySet(1);
> while (pong.get() == 0);
>
> while (ping.get() == 0);
> pong.lazySet(1);
>
> i.e., in both threads, the while loops end up before the lazySet and thus
> deadlocking.
>
> Best regards,
> David Karnok
>
>
> --
> Best regards,
> David Karnok
>
>
> _______________________________________________
> 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/20141224/b7bf5830/attachment-0001.html>


More information about the Concurrency-interest mailing list