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

Martin Buchholz martinrb at google.com
Tue Jul 19 22:42:12 EDT 2016

On Fri, Jul 15, 2016 at 12:59 AM, David Holmes <davidcholmes at aapt.net.au>
>  Also note that C++11 Cmpxhng-SeqCst  mapping for Aarch64 does not add
> any additional explicit barriers:
> https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html

I've also been struggling to understand this, having thought of strong CAS
as a single atomic bidirectional fenced operation.

 Cmpxchng SeqCst is implemented using a ldaxr followed by a stlxr

I believe it is legal for relaxed memory ops before the ldaxr to be
reordered with the ldaxr
and likewise
I believe it is legal for relaxed memory ops after the stlxr to be
reordered with the stlxr
and then to be reordered with each other (roach motel style)
without violating sequential consistency of  ldaxr and stlxr and without
interfering with the use of these operations for implementing traditional
locks.  But seqlocks are not traditional locks - they're a little

I even have a mental model that justifies such behavior.  Suppose there is
a slow read in progress and the cpu happens to already have exclusive
access to the cache line containing the cas word.  It knows that the cas
will succeed because it owns the cache line.  But because of release
semantics, the release write cannot complete until the slow read
completes.  Cpus hate stalls, so starts executing subsequent relaxed
stores.  Unlike the stlxr, which has to wait for the slow read, there is
nothing in the spec to prevent the subsequent stores from being written to
memory immediately.  If the fast write and the slow read are to the same
memory location, the read before the cas can see the write after the cas!

"""The Store-Release places no additional ordering constraints on any loads
or stores appearing after the
Store-Release instruction."""
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160719/ef5ec204/attachment.html>

More information about the Concurrency-interest mailing list