Re: [boost] [Atomic] Rationale for preventing copyconstruction/assignment?

Subject: Re: [boost] [Atomic] Rationale for preventing copyconstruction/assignment?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-05-31 02:33:55

On Thursday 30 May 2013 23:05:10 Rob Stewart wrote:
> On May 30, 2013, at 5:34 AM, "Peter Dimov" <lists_at_[hidden]> wrote:
> > Rob Stewart wrote:
> >> Assignment is a load and a store, as you note, so it isn't atomic, which
> >> is the point of an atomic type, after all. Between the load and store,
> >> the source atomic's value can change, so the copy can be wrong, hence
> >> Steven's question.> 
> > I don't think that the copy can be wrong, although I may be missing
> > something. From a cursory inspection, it seems to me that> 
> >   a1 = a2;
> > 
> > and
> > 
> >   r1 = a2;
> >   a1 = r1;
> > 
> > are equivalent. It's true that in the second case a2's value can change
> > after the first line, but it can change in the first case after the only
> > line as well (which corresponds to changing after the second line in the
> > second case), and the observable effect is the same (except in the
> > trivial case in which a1 and a2 are the same variable, but that's easily
> > taken care of).
> While what you say is true, the two are different from a sequential
> consistency POV. Since the default for atomics is sequential consistency,
> such behavior would not be correct.

Frankly, I don't quite understand this. The standard defines sequential 
consistency with regard to a single particular atomic value. I.e. both "a1 = 
a2" and "r1 = a2" must observe the effects of the last modification of a2 that 
happened before the operation. If you imply that some another side effect can 
happen in between "r1 = a2" and "a1 = r1" then that effect doesn't qualify 
that definition and need not be observed.