Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at