[cpp-threads] C++ memory model

[N.M. Maclaren]

On Sep 22 2009, Boehm, Hans wrote:
>
> 2.2: (There were other comments on this as well.) I'm not sure what the 
> right answer is here. A core question seems to be whether I can use 
> memcpy to take a snapshot of a class object containing an atomic while 
> nobody else is modifying it, and then safely examine at least other 
> fields in the copy. My assumption was that this was intended to work, and 
> thus some mixed accesses are acceptable. But I can see arguments both 
> ways.

My understanding of the intent was that, if EITHER access was by some
not-necessarily-atomic method, then appropriate synchronisation is needed
between the two actions.  That is certainly feasible to implement, and not
too tricky to use.

> 2.3: My interpretation of initialization semantics differs from what has 
> been discussed here. My assumption was that any initialization is treated 
> as one or more ordinary stores that happen before the start of the main 
> thread, and hence before the start of any thread (except for 
> function-local statics, where we should already have explicit 
> synchronization rules). Thus initializatios aren't really special as far 
> as the memory mode is concerned. But it doesn't sound like we made that 
> very clear.

More seriously, that's NOT what the standards say (assuming that C++ does
inherit from C here), and not what all designs/architectures will deliver
(unless they are told to).  In particular, if anyone implements C++ based
on a semi-distributed (e.g. PGAS) infrastructure, it is reasonable for
there to be differences when accessing uninitialised objects from the
'owning' thread and a 'non-owning' one.

It's not a critical problem, as only completely demented programmers write 
code that actually uses the initial value of uninitialised variables, even 
in the cases where C states that it is not undefined behaviour (e.g. 
unsigned char).

Regards,
Nick Maclaren.