[concurrency-interest] Semantics of compareAndSwapX

Oleksandr Otenko oleksandr.otenko at oracle.com
Wed Feb 26 07:00:18 EST 2014


Does this include compiler fences?

Alex


On 26/02/2014 03:18, Hans Boehm wrote:
> I think that's completely uncontroversial.  ARMv8 load acquire and 
> store release are believed to suffice for Java volatile loads and 
> stores respectively.  Even the fence-less implementation used a 
> release store exclusive.  Unless I'm missing something, examples like 
> this should be handled correctly by all proposed implementations, 
> whether or not fences are added.
>
> As far as I can tell, the only use case that require the fences to be 
> added are essentially abuses of CAS as a fence.
>
> Hans
>
>
> On Tue, Feb 25, 2014 at 9:45 AM, Oleksandr Otenko 
> <oleksandr.otenko at oracle.com <mailto:oleksandr.otenko at oracle.com>> wrote:
>
>     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.
>
>     Alex
>
>
>     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/20140226/b171da6f/attachment-0001.html>


More information about the Concurrency-interest mailing list