Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-11 06:17:00

From: "Wyss, Felix" <felixw_at_[hidden]>
> > Yes, you are right. Keeping a weak_ptr in thread A while all shared_ptr
> > owners are in thread B is asking for trouble. This is an inherent
> > of weak_ptr (and any non-owning pointer in general, starting with raw
> > pointers) and cannot be fixed.
> This can be fixed by providing a way to obtain a strong pointer from the
weak pointer.
> Instead of the get() method, I suggest providing a strong() method which
returns a
> shared_ptr. To make operator->() thread safe, it also must return a
shared_ptr instead of
> T*.

This shifts the responsibility to synchronize to the implementation; usually
a good thing, but unfortunately in this case this will penalize every
shared_ptr user that doesn't use weak pointers.

Currently shared_ptr uses atomic increment/decrement to manipulate the
reference count, if available. A conversion from weak to shared has to:

1. Lock the reference count;
2. Check for zero;
3. Throw if zero;
4. Increment the (strong) count;
5. Unlock and return the shared_ptr.

And, of course, for the lock to have a meaning, all shared_ptr reference
count operations must also lock.

I don't see a way to avoid the (relatively expensive) lock.

Boost list run by bdawes at, gregod at, cpdaniel at, john at