[cpp-threads] C++ memory model

[N.M. Maclaren]

On Sep 22 2009, Boehm, Hans wrote:
>> 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.

Yes.  To attempt to clarify, I believe that there is a viable alternative,
that is fairly easy to implement, but is not so easy to specify.  Here is
a loose description of what I meant:

    There is a memory model for normal access (i.e. the current one),
which says that unsynchronised access to overlapping objects is undefined
behaviour.

    If applying that rule on arbitrary mixtures of atomic and non-atomic
accesses to atomic objects lead to defined behaviour, then that's fine
and the behaviour is defined.

    If the only way in which that rule is broken is by atomic accesses to
atomic objects, then the behaviour is defined but the order of those
accesses is unspecified, unpredictable and usually unrepeatable.

Regards,
Nick Maclaren.