How does weak_ptr work?

Question

I understand how to use weak_ptr and shared_ptr. I understand how shared_ptr works, by counting the number of references in its object. How does weak_ptr work? I tried reading through the boost source code, and I'm not familiar enough with boost to understand all the things it uses.

Thanks.

Williford

See also: How do shared pointers work? – Franciscofranciska

See also shared_ptr implementation notes – Emogene

Answer 1

shared_ptr uses an extra "counter" object (aka. "shared count" or "control block") to store the reference count. (BTW: that "counter" object also stores the deleter.)

Every shared_ptr and weak_ptr contains a pointer to the actual pointee, and a second pointer to the "counter" object.

To implement weak_ptr, the "counter" object stores two different counters:

• The "use count" is the number of shared_ptr instances pointing to the object.
• The "weak count" is the number of weak_ptr instances pointing to the object, plus one if the "use count" is still > 0.

The pointee is deleted when the "use count" reaches zero.

The "counter" helper object is deleted when the "weak count" reaches zero (which means the "use count" must also be zero, see above).

When you try to obtain a shared_ptr from a weak_ptr, the library atomically checks the "use count", and if it's > 0 increments it. If that succeeds you get your shared_ptr. If the "use count" was already zero you get an empty shared_ptr instance instead.

---

EDIT: Now, why do they add one to the weak count instead of just releasing the "counter" object when both counts drop to zero? Good question.

The alternative would be to delete the "counter" object when both the "use count" and the "weak count" drop to zero. Here's the first reason: Checking two (pointer sized) counters atomically is not possible on every platform, and even where it is, it's more complicated than checking just one counter.

Another reason is that the deleter must stay valid until it has finished executing. Since the deleter is stored in the "counter" object, that means the "counter" object must stay valid. Consider what could happen if there is one shared_ptr and one weak_ptr to some object, and they are reset at the same time in concurrent threads. Let's say the shared_ptr comes first. It decreases the "use count" to zero, and begins executing the deleter. Now the weak_ptr decreases the "weak count" to zero, and finds the "use count" is zero as well. So it deletes the "counter" object, and with it the deleter. While the deleter is still running.

Of course there would be different ways to assure that the "counter" object stays alive, but I think increasing the "weak count" by one is a very elegant and intuitive solution. The "weak count" becomes the reference count for the "counter" object. And since shared_ptrs reference the counter object too, they too have to increment the "weak count".

A probably even more intuitive solution would be to increment the "weak count" for every single shared_ptr, since every single shared_ptr hold's a reference to the "counter" object.

Adding one for all shared_ptr instances is just an optimization (saves one atomic increment/decrement when copying/assigning shared_ptr instances).

Swanherd

They don't check whether the weak count and the use count are zero, and then delete the counter object. But instead they increase the weak count by one if use count is non-zero, and then only check the weak count. Why is that? – J

Since this is a little hard to explain with just a comment, I updated my answer. – Swanherd

Perhaps the reason they only add 1 at all and not 1 for each shared_ptr is that then they only need to touch the counter object once when they need to touch it anyway to call the deleter, and not everytime they decrement the use counter? – J

They have to touch the "counter" object anyway to update the "use count". However, updating the "weak count" as well would require either double-width CAS (which isn't available on many platforms) or a second CAS instruction (which is quite expensive). The "one for all" solution only requires one additional CAS per pointee, and that is after the pointee has been deleted. (The initialization doesn't require atomic instructions since there can be no other threads accessing the "counter" object at that time). – Swanherd

Answer 2

Basically, a "weak_ptr" is an ordinary "T*" pointer that lets you RECOVER a strong reference, i.e. "shared_ptr", later in the code.

Just like an ordinary T*, the weak_ptr doesn't do any reference-counting. Internally, to support reference-counting on an arbitrary type T, the STL (or any other library implementing this kind of logic) creates a wrapper object we'll call "Anchor". "Anchor" exists solely to implement the reference count and "when count is zero, call delete" behavior we need.

In a strong reference, the shared_ptr implements its copy, operator=, constructor, destructor, and other pertinent APIs to update "Anchor"'s reference count. This is how a shared_ptr ensures that your "T" lives for exactly as long as somebody is using it. In a "weak_ptr", those same APIs just copy the actual Anchor ptr around. They do NOT update reference counts.

This is why the most important APIs of "weak_ptr" are "expired" and the poorly-named "lock". "Expired" tells you if the underlying object is still around- i.e. "Has it already deleted itself because all strong references went out of scope?". "Lock" will (if it can) convert the weak_ptr to a strong reference shared_ptr, restoring reference-counting.

BTW, "lock" is a terrible name for that API. You aren't (just) invoking a mutex, you're creating a strong reference from a weak one, with that "Anchor" acting. The biggest flaw in both templates is that they did not implement operator->, so to do anything with your object you have to recover the raw "T*". They did this mostly to support things like "shared_ptr", because primitive types don't support the "->" operator.

Vezza

You wrote: In a "weak_ptr", those same APIs just copy the actual Anchor ptr around. They do NOT update reference counts. That's incorrect; they update the weak reference count, which manages the lifetime of the Anchor itself. Otherwise, how would you know when to free the Anchor's own memory? Also, std::shared_ptr does implement operator->; I don't know how you got the idea that it doesn't. – Alena

STL is the abbreviation of Standard Template Library, ie containers, iterator, etc. Smart pointers are not part of it. – Hypothec