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
> Instead of the get() method, I suggest providing a strong() method which
> shared_ptr. To make operator->() thread safe, it also must return a
shared_ptr instead of
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk