[cpp-threads] C++ memory model

[Lawrence Crowl]

On 9/22/09, Boehm, Hans <hans.boehm at hp.com> 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?

The current draft has a deleted copy constructor and a deleted copy
assignment operator.  So, if you want to wrap it in a copyable class,
the wrapper needs explicit code.

    class wrapper {
        atomic<int> ai;
    public:
        wrapper( const wrapper& other )
        : ai( other.ai.load(memory_order_relaxed) ) { }
    };

Given this code, I see no reason to expect undefined behavior.

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

You mean in that we would have either exclusively atomic or
exclusively non-atomic operations on a location?

That exclusivity is what I thought we were doing.

> 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.

With the deleted copy operations, memcpy is not defined to work,
and you have no way to legally do a bit copy anyway.

-- 
Lawrence Crowl