[concurrency-interest] Semantics of compareAndSwapX

Hans Boehm boehm at acm.org
Tue Feb 25 11:21:42 EST 2014


Could someone post a test case that they think should work, but that
doesn't work with the acquire/release implementation (without added
fences)?  Clearly it does not work as a general purpose fence replacement,
e.g. when used on an object accessed by only one thread.  But I hope that
was not intended.  It does seem to me that it does preserve the property
that properly synchronized programs are sequentially consistent.

It seems to have the same synchronization properties as if all operations
on an atomic class were implemented with locks.  This is clearly allowed
for C++, and I would have presumed that it's intended to be allowed for
j.u.c.

Definitive answers here would be a lot easier if we had more precise
specifications, both for Java and the ARMv8 ISA.

Hans


On Mon, Feb 24, 2014 at 9:13 AM, Andrew Haley <aph at redhat.com> wrote:

> On 02/24/2014 02:47 PM, Oleksandr Otenko wrote:
> > Hmmm...
> >
> > Can someone clarify this issue? I don't know ARM instructions, yet it
> > seems the discussion contradicts itself.
> >
> > This here observation summarizes that "GCC's usage of ....<instruction
> > sequence> is ok" despite it not being a full barrier, and that the
> > reordering of memop_A and memop_C before and after CAS respectively, is
> > allowed.
> >
> > Yet further in the discussion Doug mentions it is meant to be a volatile
> > read+volatile write, which would preclude the reordering of memop_A and
> > memop_C.
> >
> > So, is that reordering allowed or not?
>
> Not by Java, no.  A ldx.acq ... stx.rel is not enough for Java's
> compareAndSwap.  We are sure about that.
>
> However, according to Stephan Diestelhorst it *is* enough for the
> implementation of the C++11 atomics, and the notion of sequential
> consistency of atomics.
>
> I do not know what Stephan bases that claim on.
>
> Andrew.
> _______________________________________________
> 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/20140225/024ddec0/attachment.html>


More information about the Concurrency-interest mailing list