The control block allocated when a shared_ptr
is created from a plain pointer contains both the reference counter for the object and the pointer to the object itself and the custom deleter object if any. When that reference counter reaches zero the object is released and the pointer is set to null. So, when the object reference counter is zero it means that the object is gone.
For x86 and x86-64 they use atomic operations and no explicit locking (no mutex or spinlock). The trick of the implementation is a special lock-free (code language for busy spin) function atomic_conditional_increment
that only increments the object reference counter if it is not zero. It is used in the implementation of weak_ptr::lock
function to cope with a race when more than one thread tries to create a shared_ptr
from the same weak_ptr
with object reference counter being zero. See http://www.boost.org/doc/libs/1_52_0/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp
The control block itself is shared between shared_ptr
's and weak_ptr
's and has another reference counter for itself, so that it stays alive till the last reference to it is released.
When a shared_ptr
is reassigned it points to another control block, so that a control block only ever points to one same object. In other words, there is no replacement of one object with another in the control block.