[cpp-threads] C++ memory model

[N.M. Maclaren]

On Sep 22 2009, Lawrence Crowl wrote:
>
>> While I personally agree with your solution, which has similarities to
>> the one that Fortran has adopted, it has the consequence of preventing a
>> lot of reasonable constructions.  For example, such objects could not be
>> accessed by any of the functions in <cstring>, nor could they be
>> transferred in I/O.  It's a knotty problem.
>
>I think the lack of 'trivally copyable' saves the day.

Yes, but were the consequences intended? My understanding is that the 
answer is that they weren't. but you more active people may have changed 
the intent. Whichever decision is taken (and there are reasonable grounds 
for taking either of them), it should be clear what the intent is.

>> The reason for that is the nasty question of whether an object HAS an
>> initial value as an array of unsigned char - i.e. precisely which
>> meaning of "undefined" applies.  There have been (and perhaps still are)
>> architectures where the value returned may vary according to the type of
>> access.  It isn't implausible that the thread that allocates an object
>> might see a different initial value from other threads, especially for
>> pointers.  Is that allowed?
>
>I think allowing it would really confuse programmers.  So, I would
>rather not.  The implication is, I think, that any dynamic initialization
>must be a relaxed store.

OK.  Then the standard needs fixing.  It's not a big deal - all it needs is
a definition of "indeterminate value" to mean what a relaxed store of an
unspecified non-trap value.  That could be restricted to apply to just
atomics, or not, whichever people prefer.

Regards,
Nick Maclaren.