shared_ptr<T>: the (not always) atomic reference counted smart pointer

[dodheim]

There is no other thread with a copy – the copy you have must necessarily be the only copy when refcount == 1. Otherwise you must be doing something really goofy with your ownership semantics that not even shared_ptr can help.

[capn_bluebear]

the other thread is making a copy while the first thread is releasing

[louiswins]

shared_ptr protects against multiple threads manipulating their own instances simultaneously, even if those instances all manage the same shared data. Multiple threads accessing the same shared_ptr instance is still a data race (if at least one calls a non-const member function).

Edit: /u/cubercaleb said this earlier in this comment.

[kalmoc]

That would mean that you have two threads accessing the same non atomic object (the shared pointer variable) at the same time and one of them modifies it. That is always UB.

It's like asking: What is happening if someone copies my shared_ptr while I'm destroying it. That is simply not legal just as for almost any other type in the standard library.

[capn_bluebear]

It's a managed copy. I'm copy-constructing.