[cpp-threads] SC on PPC

[Nick Maclaren]

"Nelson, Clark" <clark.nelson at intel.com> wrote:
>
> 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.

Absolutely.  That is particularly relevant to the papers on non-memory
actions I am about to get to you!

Those things range from nasty to totally repulsive, often with no
clear correspondence between their basic concepts and memory
release/acquire.  So I propose that the portable definition is that
there is a heavyweight, fully-ordered mechanism and anything more
should (preferably, but not compulsorily) be implementation-defined.

For a gibbering example of that, think of the IEEE 754 overflow
flag (and the draft HAS included the function to test that!)  I have
used architectures where the flag can be visible in advance of the
value being stored, and others where it can be in arrears of that.
And, for some of those, forcing it to behave in a memory-like fashion
could slow code down by a factor of four.

Well, excluding vector machines, where the factor could be a thousand,
but I don't think we shall see those again :-)


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679