What is the cyclic dependency issue with shared_ptr?

by

The problem isn’t that complex. Let --> represent a shared pointer:

The rest of the program  --> object A --> object B
                                    ^     |
                                     \    |
                                      \   v
                                        object C

So we’ve got ourselves a circular dependency with shared pointers. What’s the reference count of each object?

A:  2
B:  1
C:  1

Now suppose the rest of the program (or at any rate the part of it that holds a shared pointer to A) is destroyed. Then the refcount of A is reduced by 1, so the reference count of each object in the cycle is 1. So what gets deleted? Nothing. But what do we want to be deleted? Everything, because none of our objects can be reached from the rest of the program any more.

So the fix in this case is to change the link from C to A into a weak pointer. A weak pointer doesn’t affect the reference count of its target, which means that when the rest of the program releases A, its refcount hits 0. So it’s deleted, hence so is B, hence so is C.

Before the rest of the program releases A, though, C can access A whenever it likes by locking the weak pointer. This promotes it to a shared pointer (and increases the refcount of A to 2) for as long as C is actively doing stuff with A. That means if A is otherwise released while this is going on then its refcount only falls to 1. The code in C that uses A doesn’t crash, and A is deleted whenever that short-term shared pointer is destroyed. Which is at the end of the block of code that locked the weak pointer.

In general, deciding where to put the weak pointers might be complex. You need some kind of asymmetry among the objects in the cycle in order to choose the place to break it. In this case we know that A is the object referred to by the rest of the program, so we know that the place to break the cycle is whatever points to A.

More Related Contents:

  1. shared_ptr and weak_ptr differences
  2. weak_ptr, make_shared and memory deallocation
  3. When to use virtual destructors?
  4. How do I call ::std::make_shared on a class with only protected or private constructors?
  5. shared_ptr to an array : should it be used?
  6. Difference in make_shared and normal shared_ptr in C++
  7. Differences between unique_ptr and shared_ptr [duplicate]
  8. Why isn’t there a std::shared_ptr specialisation?
  9. Why do std::shared_ptr work
  10. Why shared_from_this can’t be used in constructor from technical standpoint?
  11. Should we pass a shared_ptr by reference or by value?
  12. std::shared_ptr of this
  13. C++ – passing references to std::shared_ptr or boost::shared_ptr
  14. Passing shared pointers as arguments
  15. How to avoid memory leak with shared_ptr?
  16. Boost async_* functions and shared_ptr’s
  17. How does weak_ptr work?
  18. How to release pointer from boost::shared_ptr?
  19. Passing shared_ptr as shared_ptr
  20. std::shared_ptr thread safety explained
  21. Should I use shared_ptr or unique_ptr
  22. Is boost shared_ptr thread safe?
  23. Is make_shared really more efficient than new?
  24. How do shared pointers work?
  25. Why would I std::move an std::shared_ptr?
  26. Example to use shared_ptr?
  27. shared_ptr: horrible speed
  28. Using shared_ptr in dll-interfaces
  29. Private constructor and make_shared
  30. Problems using member function as custom deleter with std::shared_ptr

Leave a Comment