[concurrency-interest] Does StampedLock need a releaseFence in theory?
davidcholmes at aapt.net.au
Fri Jul 15 09:07:53 EDT 2016
Andrew Haley writes:
> Sent: Friday, July 15, 2016 9:51 PM
> To: Will Deacon <will.deacon at arm.com>
> Cc: Martin Buchholz <martinrb at google.com>; Doug Lea
> <dl at cs.oswego.edu>; concurrency-interest <concurrency-
> interest at cs.oswego.edu>
> Subject: Re: [concurrency-interest] Does StampedLock need a releaseFence
> in theory?
> 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.
Is this "conceive" in a thought-experiment sense or something realistic? Is this just an unintended hole in the abstract architectural model or a deliberate allowance for such "optimizations"?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest