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

David Holmes 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"?

David 
 
> Andrew.
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list