Memory model

[Kevlin Henney]

In message 
<65953E8166311641A685BDF71D865826058C58 at cacexc12.americas.cpqcorp.net>, 
"Boehm, Hans" <hans.boehm at hp.com> writes
>
>I think that in all cases, we have choices for C++:
[...]
>(2) The more I think about this one, the more it worries me.
>I think we want to outlaw overwriting adjacent fields, except
>in the bit-field case.  And I think that has minimal impact
>on performance.  But consider (ri are locals/registers whose
>address is not taken, x is global and possibly shared):
>
>r1 = x;
>for ( ... = r1; ...; ... ) {... } // Messy computation; touches no globals.
>                                           // No further references to r1.
>... r1 ...
>
>Let's say the compiler runs out of registers compiling the loop,
>and wants to spill r1, can it reload r1 from x, or does it need
>a separate spill location?  My guess is that most current C++ compilers
>would reload from x if they could determine that to be safe for
>sequential code.  Changing this probably would affect performance.
>Thus it's not at all clear to me that we want to prohibit a read
>from being repeated.
>
>If x is actually a shared global, I think you do not want to allow
>the compiler to reload from x.  But there is an argument that in that
>case either x should be volatile, or the reference to x should use
>the atomic operations library.

And another question is what constraints should be placed on non-MT 
code? Overwriting adjacent fields may be appropriate in a sequential 
program where no behavioural difference could arise. And what is the 
effect on existing ABIs?

>(3) If we allow races, we need to say something about atomicity here.
>This may get us into trouble on some low end hardware?

To continue the previous point, this raises the question of degree of 
conformance required for any memory model proposed. Is the model truly 
general so that, in the limit with a single thread, it also specifies 
conformance for existing C++ sequential code? Or is it an optional 
extra, ie if there is more than a single thread active in the code then 
a memory and execution model must conform to this newly standardised 
behaviour?

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________