[cpp-threads] SC on PPC

[Raul Silvera]

Clark Nelson wrote on 05/03/2007 01:39:15 PM:

> > 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.
>
> My apologies if I'm misunderstanding your point, but you seem to be
> saying something with which I would strongly disagree. So just in case
> you are....
>
> It is *not* important for the standard to clearly define how every
> possible operation interacts with every other possible operation. What
> *is* important is to specify rules for how portable multi-threading code
> can be written. If, for example, the rules were to say it is necessary
> to use both acquire and release to properly communicate between threads,
> it could just say that failing to use both results in undefined
> behavior. The exact behavior of improperly written code doesn't need to
> be specified.
>

I agree... I'm not advocating trying to characterize undefined behavior;
my point is that the standard must clearly state which combinations
of operations (if any) result in undefined behavior, and just as
importantly it must precisely define the semantics of operations that
are allowed.

In general we can expect that inter-thread communication will occur
through a combination of strong atomics, weak atomics, fences and locks.
I believe some forms of cooperation between these different mechanisms
is possible and should be characterized in the memory model.

In particular, weak atomics and fences will frequently be used in
conjunction. So far we've been thinking of strong atomics as a
specialized form of weak atomics; from that it would follow that at
least strong atomics, weak atomics and fences will be allowed to
interoperate. I'm just calling for clear rules on what guarantees will
be provided to the programmer for this situation.

--
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