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

Subject: Re: [boost] [Atomic] Rationale for preventing copy construction/assignment?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2013-05-29 23:49:08

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