[cpp-threads] C++ memory model

[Boehm, Hans]

> From: N.M. Maclaren 
> Sent: Tuesday, September 22, 2009 2:07 AM
> 
> 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.

I agree with Nick that this strikes me as a bit more draconian that what I previously thought we were saying.  Just to be clear, I think that in this interpretation, if I create a copy of a class object containing an atomic in a single-threaded executable, never accessing the atomic in the copy, I get undefined behavior?

I think that would make us completely consistent with the interpretation in Mark's and Peter's paper (4.2.4).

I think I can live with that, but I do think we need to be a bit clearer about it.  I suspect the alternatives may be much harder to specify?  One could conceive of atomics implementations, e.g. as pointers to a special locations, for which a bitwise copy woule be meaningless, though these seem to be unlikely.  And making a copy that is not accessed would still be safe.

Hans