[concurrency-interest] Does StampedLock need a releaseFence in theory?

Martin Buchholz martinrb at google.com
Thu Jul 14 11:27:00 EDT 2016


On Thu, Jul 14, 2016 at 1:23 AM, Andrew Haley <aph at redhat.com> wrote:

> On 14/07/16 01:53, Hans Boehm wrote:
> > An ARMv8 compareAndSet operation (using only acquire and release
> > operations, not dmb, as it should be implemented) will behave like the
> > lock-based one in this respect.  I think the current code above is
> > incorrect on ARMv8 (barring compensating pessimizations elsewhere).
>
> Umm, what?  The ARMv8 compareAndSet has a sequentially consistent store.
> I guess I must be missing something important.


(Pretending to be Hans here ...)
The idea is that all ARMv8 "load-acquire/store-release" operations
(including those used for implementing CAS) are sequentially consistent
when considered as a group in the same way that all "synchronization
actions" in Java are, but they can still be reordered with plain
reads/writes, just like Java plain variable access can be reordered with
volatile variable access (unless a happens-before relationship exists).

The section in
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
on aarch64 should be useful.

ldar corresponds to Java volatile read
stlr corresponds to Java volatile write
CAS is implemented using a ldaxr followed by stlxr which is efficient, but
allows subsequent writes to move in between the ldaxr and the stlxr.

(Back to being Martin ...)
Reordering a plain store from after to before a stlxr (rather than
non-exclusive stlr) is still rather surprising because it looks like a
speculative store - we don't know yet whether the stlxr will succeed.
Unlike the case where we implement CAS via a lock.  Am I thinking too
atomically?  Perhaps the stlxr instruction implementation exclusively
acquires the cache line, sees that it surely will succeed, but will be slow
because pending memory operations must be completed first.  But no reason
we can't start executing future instructions in the meantime!?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160714/af1ce621/attachment.html>


More information about the Concurrency-interest mailing list