[concurrency-interest] Semantics of compareAndSwapX

Oleksandr Otenko oleksandr.otenko at oracle.com
Tue Feb 25 12:45:20 EST 2014

Not sure what you are asking for - a Java or C++ example? (I don't know 
C++ semantics)

But emptying a cyclic buffer is a example where CAS must behave at least 
as a volatile store:

long w_pos; // updated in a synchronized block
AtomicLong r_pos;
Object [] array;

long r;
while ((r = r_pos.get()) != w_pos) {
   Object v = array[(int)(r % array.length)];
   if (r_pos.compareAndSet(r, r+1)) return v;

If r_pos.compareAndSet does not have barriers of a volatile store, then 
volatile loads are hoistable.


On 25/02/2014 16:21, Hans Boehm wrote:
> 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 
> <mailto: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
>     <mailto: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/767ae389/attachment.html>

More information about the Concurrency-interest mailing list