Copyable Atomic

Question

I find it pretty annoying that c++11 atomics can't be copied. The reasons for this have been discussed e.g. here and I don't want to argue about them now. However, I find myself repeatedly in situations, where I want to copy data structures around that contain atomics. Usually BEFORE they are actually used in a multithreaded context (e.g. in order to return them from a factory function, or to store them in a vector etc.).

In order to solve that problem without having to manually write a copy constructor over and over again, I decided to write a simple class, that publicly derives from std::atomic and adds those functionality:

/**
 * Drop in replacement for std::atomic that provides a copy constructor and copy assignment operator.
 *
 * Contrary to normal atomics, these atomics don't prevent the generation of 
 * default constructor and copy operators for classes they are members of.
 * 
 * Copying those atomics is thread safe, but be aware that 
 * it doesn't provide any form of synchronization.
 */
template<class T>
class CopyableAtomic : public std::atomic<T>
{
public:
    //defaultinitializes value
    CopyableAtomic() : 
        std::atomic<T>(T{})
    {}

    constexpr CopyableAtomic(T desired) : 
        std::atomic<T>(desired) 
    {}

    constexpr CopyableAtomic(const CopyableAtomic<T>& other) :
        CopyableAtomic(other.load(std::memory_order_relaxed))
    {}

    CopyableAtomic& operator=(const CopyableAtomic<T>& other) {
        this->store(other.load(std::memory_order_relaxed), std::memory_order_relaxed);
        return *this;
    }
};

In my toy examples this worked pretty well, however, I'm not sure, if I really considered all possible ramifications of this - deriving from standard library types feels awkward enough and when it comes to synchronization primitives I feel a bit like playing with fire (or juggling with razorblades to quote Herb Sutter).

So what I would like to know (aside from general improvement suggestions, or alternative approaches):

• Can this really serve as a drop-in replacement everywhere, where you would use a normal atomic (especially also with CAS instructions).
• Is my claim, that the copy constructor / assignment operator is threadsafe correct (both with respect to this as well as with respect to other)
• Can you think of any performance regressions that this would introduce when used as a synchronization primitive instead of a std::atomic (e.g. because - for some reasons - compilers treat std::atomics in a way they don't / can treat this class)

Answer 1

Difference in default constructor

std::atomic<T>'s default constructor is trivial - yours isn't. If your goal is to simply add copy semantics, I would maintain this same behavior:

CopyableAtomic() = default;

Memory orders

I'm not sure about relaxed here. You probably want to ensure consistent orderings where you use this object, so I would change the load()s to use std::memory_order_acquire and the store() to use std::memory_order_release. That is:

CopyableAtomic& operator=(const CopyableAtomic<T>& other) {
    this->store(
        other.load(std::memory_order_acquire),
        std::memory_order_release);
    return *this;
}

Otherwise, you might get unexpected reorderings. Better to be on the safe side if you're writing a class like this.

Otherwise

This looks perfectly fine to me. With the exception of copying, this is precisely a std::atomic so it should have all the same behavior everywhere - so it should be able to be a straight-forward drop in replacement in all places.