What is the difference between std::shared_ptr and std::atomic<std::shared_ptr> aka. std::experimental::atomic_shared_ptr?

atomic, c++, c++11, concurrency, smart-pointers

Solution

The atomic "thing" in `shared_ptr` is not the shared pointer itself, but the control block it points to. meaning that as long as you don't mutate the `shared_ptr` across multiple threads, you are ok. do note that copying a `shared_ptr` only mutates the control block, and not the `shared_ptr` itself.

std::shared_ptr<int> ptr = std::make_shared<int>(4);
for (auto i =0;i<10;i++){
   std::thread([ptr]{ auto copy = ptr; }).detach(); //ok, only mutates the control block 
}

Mutating the shared pointer itself, such as assigning it different values from multiple threads, is a data race, for example:

std::shared_ptr<int> ptr = std::make_shared<int>(4);
std::thread threadA([&ptr]{
   ptr = std::make_shared<int>(10);
});
std::thread threadB([&ptr]{
   ptr = std::make_shared<int>(20);
});

Here, we are mutating the control block (which is ok) but also the shared pointer itself, by making it point to a different values from multiple threads. This is not ok.

A solution to that problem is to wrap the `shared_ptr` with a lock, but this solution is not so scalable under some contention, and in a sense, loses the automatic feeling of the standard shared pointer.

Another solution is to use the standard functions you quoted, such as `std::atomic_compare_exchange_weak`. This makes the work of synchronizing shared pointers a manual one, which we don't like.

This is where atomic shared pointer comes to play. You can mutate the shared pointer from multiple threads without fearing a data race and without using any locks. The standalone functions will be members ones, and their use will be much more natural for the user. This kind of pointer is extremely useful for lock-free data structures.

Problem

I've read the following article by Antony Williams and as I understood, in addition to the atomic shared count in `std::shared_ptr`, in `std::atomic<std::shared_ptr<T>>` (in the article, known as `std::experimental::atomic_shared_ptr`) the actual pointer to the shared object is also atomic. But when I read about reference-counted version of `lock_free_stack` described in Antony's book about C++ Concurrency it seems for me that the same aplies also for `std::shared_ptr`, because functions like `std::atomic_load`, `std::atomic_compare_exchnage_weak` are applied to the instances of `std::shared_ptr`. ``` template <class T> class lock_free_stack { public: void push(const T& data) { const std::shared_ptr<node> new_node = std::make_shared<node>(data); new_node->next = std::atomic_load(&head_); while (!std::atomic_compare_exchange_weak(&head_, &new_node->next, new_node)); } std::shared_ptr<T> pop() { std::shared_ptr<node> old_head = std::atomic_load(&head_); while(old_head && !std::atomic_compare_exchange_weak(&head_, &old_head, old_head->next)); return old_head ? old_head->data : std::shared_ptr<T>(); } private: struct node { std::shared_ptr<T> data; std::shared_ptr<node> next; node(const T& data_) : data(std::make_shared<T>(data_)) {} }; private: std::shared_ptr<node> head_; }; ``` What is the exact difference between these two types of smart pointers? If the pointer in a `std::shared_ptr` instance is not atomic, why it is possible write the above lock-free stack implementation?

Original source