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

Andrew Haley aph at redhat.com
Fri Jul 15 09:36:34 EDT 2016

On 15/07/16 12:50, Andrew Haley wrote:
> On 15/07/16 09:47, Will Deacon wrote:
>> On Fri, Jul 15, 2016 at 08:52:00AM +0100, Andrew Haley wrote:
>>> I don't think it matters.  The code will always look like
>>>     stlxr status, data, [addr]
>>>     cbnz status, retry
>>>     str r1, [data1]
>>>     str r2, [data2]
>>> The stores are control-dependent on the CBNZ: they cannot be
>>> speculated before the STLXR.
>> I'm not so sure about that, unfortunately. You can conceive of a
>> microarchitecture that knows stlxr can never fail, in which case the
>> control dependency can be folded away. If you want ordering between the
>> stlxr and the subsequent stores, you need an explicit barrier.
> That's interesting.  I'm surprised that such an optimization can change
> the ordering rules, though.

Thinking about it some more, I am very skeptical.  For example, it is a
common trick to enforce ordering by using an address dependency, such as:

    ldr x1, [addr1]
    eor x0, x0, x1
    eor x0, x0, x1
    ldr x2, [x0]

Here, the load of x2 must be after the load of x1 because of the
address dependency.  A "smart" microarchitecture could fold away the
EORs (and maybe even the load of x1).  But I'm sure that would not be
permitted by the specification.


More information about the Concurrency-interest mailing list