CODEWITHSUNDEEP
c++multithreadingc++11atomicreference-counting
Siler
Siler

Reputation: 9504

Atomic Reference Counting

I'm trying to understand exactly how thread-safe, atomic reference counting works, for example as with std::shared_ptr. I mean, the basic concept is simple, but I'm really confused about how the decref plus delete avoids race conditions.

This tutorial from Boost demonstrates how an atomic thread-safe reference counting system can be implemented using the Boost atomic library (or the C++11 atomic library).

#include <boost/intrusive_ptr.hpp>
#include <boost/atomic.hpp>

class X {
public:
  typedef boost::intrusive_ptr<X> pointer;
  X() : refcount_(0) {}

private:
  mutable boost::atomic<int> refcount_;
  friend void intrusive_ptr_add_ref(const X * x)
  {
    x->refcount_.fetch_add(1, boost::memory_order_relaxed);
  }
  friend void intrusive_ptr_release(const X * x)
  {
    if (x->refcount_.fetch_sub(1, boost::memory_order_release) == 1) {
      boost::atomic_thread_fence(boost::memory_order_acquire);
      delete x;
    }
  }
};

Okay, so I get the general idea. But I don't understand why the following scenario is NOT possible:

Say the refcount is currently 1.

  1. Thread A: atomically decrefs the refcount to 0.
  2. Thread B: atomically increfs the refcount to 1.
  3. Thread A: calls delete on the managed object pointer.
  4. Thread B: sees the refcount as 1, accesses the managed object pointer... SEGFAULT!

I can't understand what prevents this scenario from occurring, since there is nothing preventing a data race from between the time the refcount reaches 0, and the object is deleted. Decrefing the refcount and calling delete are two separate, non-atomic operations. So how is this possible without a lock?

Upvotes: 27

Views: 14748

Answers (5)

MikeMB
MikeMB

Reputation: 21166

You probably overestimate the threadsafety a shared_ptr provides.

The essence of atomic ref counting is to ensure that if two different instances of a shared_ptr (that are managing the same object) are accessed/modified, there will be no race condition. However, shared_ptr doesn't ensure thread safety, if two threads access the same shared_ptr object (and one of them is a write). One example would be e.g. if one thread dereferences the pointer, while the other resets it.
So about the only thing shared_ptr gurantees is that there will be no double delete and no leak as long as there is no race on a single instance of a shared_ptr (It also doesn't make accesses to the object it points to threadsafe)

As a result, also creating a copy of a shared_ptr is only safe, if there is no other thread that could delete/reset it at the same time (you could also say, it is not internally synchronized). This is the scenario you describe.

To repeat it once more: Accessing a single shared_ptr instance from multiple threads where one of those accesses is a write to the pointer is still a race condition.

If you want to e.g. copy a std::shared_ptrin a threadsafe manner, you have to ensure that all loads and stores happen via std::atomic_... operations which are specialized for shared_ptr.

Upvotes: 30

David Schwartz
David Schwartz

Reputation: 182855

Thread B: atomically increfs the refcount to 1.

Impossible. To increment the reference count to one, the reference count would have to be zero. But if the reference count is zero, how is thread B accessing the object at all?

Either thread B has a reference to the object or it doesn't. If it does, then the reference count cannot be zero. If it does not, then why is it messing with an object managed by smart pointers when it has no reference to that object?

Upvotes: 3

kfsone
kfsone

Reputation: 24269

The implementation doesn't provide or require such a guarantee, avoidance of the behavior you are describing is predicated on the proper management of counted-references, usually done through a RAII class such as std::shared_ptr. The key is to entirely avoid passing by raw pointer across scopes. Any function which stores or retains a pointer to the object must take a shared pointer so that it can properly increment the ref count.

void f(shared_ptr p) {
   x(p); // pass as a shared ptr
   y(p.get()); // pass raw pointer
}

This function was passed a shared_ptr so the refcount was already 1+. Our local instance, p, should have bumped the ref_count during copy-assignment. When we called x if we passed by value we created another ref. If we passed by const ref, we retained our current ref count. If we passed by non-const ref then it's feasible that x() released the reference and y is going to be called with null.

If x() stores/retains the raw pointer, then we may have a problem. When our function returns the refcount might reach 0 and the object might be destroyed. This is our fault for not correctly maintaining ref count.

Consider:

template<typename T>
void test()
{
    shared_ptr<T> p;
    {
        shared_ptr<T> q(new T); // rc:1
        p = q; // rc:2
    } // ~q -> rc:1
    use(p.get()); // valid
} // ~p -> rc:0 -> delete

vs

template<typename T>
void test()
{
    T* p;
    {
        shared_ptr<T> q(new T); // rc:1
        p = q; // rc:1
    } // ~q -> rc:0 -> delete
    use(p); // bad: accessing deleted object
}

Upvotes: 3

user2249683
user2249683

Reputation:

For std::shared_ptr a reference counting change is thread safe, but not the access to the content of the `shared_ptr.

Regarding boost::intrusive_ptr<X>, this is no answer.

Upvotes: 1

Paladine
Paladine

Reputation: 523

Your scenario is not possible because Thread B should have been created with an incremented refcount already. Thread B should not be incrementing the ref count as the first thing it does.

Let's say Thread A spawns Thread B. Thread A has the responsibility to increment the ref count of the object BEFORE creating the thread, to guarantee thread safety. Thread B then only has to call release when it exits.

If Thread A creates Thread B without incrementing the ref count, bad things might happen as you've described.

Upvotes: 4

Related Questions