[cpp-threads] SC on PPC

[Raul Silvera]

Hans Boehm wrote on 05/02/2007 11:06:12 AM:
> On Wed, 2 May 2007, Alexander Terekhov wrote:
>
> >
> > I'm talking about the cost of acquire on PPC.
> >
> > P1: x.store_relaxed(1)
> > P2: if (x.load_relaxed()==1) { y.store_release(1) }
> > P3: if (y.load_acquire()==1) { Assert(x.load_relaxed()==1) }
> >
> > wont abort with
> >
> > load_acquire:   load;"branch never taken";isync // see B.2.3 Safe
> > Fetch (Book II).
> > store_release:  lwsync;store
> >
> > I don't want to have more constrained
> >
> > load_acquire:   load;lwsync
> >
> Certainly that's an interesting question.  On the other hand, I'm saying
> that in the proposed C++ memory model, this is allowed to abort unless
you
> change the initial store_relaxed to a store_release.
>
> I susoect this has little bearing on the rest of your discussion, though.
> And I can't think of realistic situations in which you wouldn't need the
> store_release in P1 anyway.

Thanks for the clarification, Hans. I have all along been thinking of
symmetric
acquire and releases, as defined on N2153. So your proposal is to have
causality
be triggered by release but not acquire? Or do you need both acquire and
releases
to trigger causality? Do you foresee this changing on the next version of
the
model?

I realize that this is not so interesting if all you have is
acquire/release
operations, but once you include relaxed operations (and fences) it is
important
to clearly define how they interact with each other. In particular, in
Alexander's
example above, why is the store_relaxed() from P1 insufficient even though
P1 doesn't
issue any other memory operations? What if there was a release_fence()
before that
store_relaxed()?

--
Raúl E. Silvera         IBM Toronto Lab   Team Lead, Toronto Portable
Optimizer (TPO)
Tel: 905-413-4188 T/L: 969-4188           Fax: 905-413-4854
D2/KC9/8200/MKM