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

Hans Boehm boehm at acm.org
Thu Jul 14 15:19:35 EDT 2016


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

>
> > (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.
>
> But even CAS via a lock has the roach motel property, so we're used to
> the idea of stores and loads moving into a critical section: none of
> this should surprise people.
>
> > 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.
>
> I don't think it has to be so complicated.  An out-of-order
> implementation can move stores which are after this stlxr to before it
> simply because there is no logic preventing it from doing so.  Whether
> this is a realistic or useful property of a real machine is a whole
> 'nother matter.
>
> Andrew.
>
I think Martin does have a point here that I missed the first time.  The
data stores are "control-dependent" on the store in the CAS
implementation.  ARM and Power effectively preserve ordering between
control-dependent stores, though not a store followed by a load. But we
really only care about stores here.

At least that's probably true; I'm not 100% sure whether stlxr success is
viewed as dependent on the store itself for purposes of determining
ordering. (Will Deacon might be able to answer?)

There is also another subtlety here in the definition of
"control-dependency" in that arguably the control paths have rejoined. My
understanding is that ARM's definition of "control-dependency" is not
affected by such rejoining, but Itanium's is.

A spin-lock-based implementation would indeed still have the issue, since
the lock release there is a plain store.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160714/eb3a904f/attachment.html>


More information about the Concurrency-interest mailing list