[concurrency-interest] Semantics of compareAndSwapX

Hans Boehm boehm at acm.org
Tue Feb 25 22:18:53 EST 2014


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> 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> 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/d96a4e46/attachment.html>


More information about the Concurrency-interest mailing list