Boost logo

Boost :

Subject: Re: [boost] [Atomic] Rationale for preventing copy construction/assignment?
From: Collin Dauphinee (collin_at_[hidden])
Date: 2013-05-30 00:59:41


On 5/29/2013 8:49 PM, Steven Watanabe wrote:
> AMDG
>
> On 05/29/2013 01:22 PM, Collin Dauphinee wrote:
>> I've recently noticed that boost::atomic<T> prevents assignment from
>> boost::atomic<T>, as well as copy construction. I'm having trouble
>> understanding why this decision was made, as it makes boost::atomic<T> (and
>> classes with a boost::atomic<T> member) very hard to store in containers,
>> and I can't immediately see any safety issues that would be caused by
>> allowing copy operations.
>>
>> What is the rationale for not allowing assignment or copy construction from
>> another boost::atomic<T>?
>>
> How would you make it sequentially consistent
> without using a mutex?
>
> In Christ,
> Steven Watanabe
>

I don't view an assignment as a single operation, so I wouldn't expect
both reading the source and storing it's value in the destination to be
sequentially consistent. I would expect an assignment to be a
'convenience' function wrapping store and load, because as far as I'm
aware, there is no way to do this sequentially without a mutex.

My issue is stemming from wanting to store an object containing a few
member variables, one being an atomic counter, in an std::map. The work
around is to either implement the assignment operator just to accomodate
the counter, or wrapping the counter in a class providing the same
interface. Both result in bad code, and I think this is something an
average user would run into fairly often.

I imagine that the situation where a user actually cares about the
sequential consistency of assignment would be very rare, and in the
cases where the user does care, they would realize the cost of
guaranteeing sequential consistency for an assignment and check the
documentation. Again, this would be completely for convenience.

I could definitely be wrong on all of this, though.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk