From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-04-15 07:58:43
Eric Niebler wrote:
> I'm thinking about replacing some uses of shared_ptr with
> intrusive_ptr, but I've got questions. One of the nice things about
> shared_ptr is the lock-free thread-safe ref counting. I want my
> intrusive_ptr to have the same safety and efficiency, but I don't see
> how to get it. I see $boost_root/detail/atomic_count.hpp, but
> shared_ptr doesn't use it. Why not? And why is it in detail/? Should
> I not consider using it?
shared_ptr doesn't use atomic_count because the addition of weak_ptr has
made atomic_count's interface insufficient.
atomic_count is in detail:: because I didn't consider it ready for boost::.
On the other hand, if it works for you, there is no reason to not use it.
> Taking in the bigger picture, intrusive_ptr requires people to write
> their own add_ref and release functions, most of which will probably
> end up using ++ and -- on a plain integer. This is totally broken in
> multi-threaded applications, right?
Using ++ and -- on a plain integer without synchronization is broken in MT
apps, yes.
> Isn't it dangerous to not provide
> complementary utilities for correctly managing reference counts? It
> seems to me intrusive_ptr is impossible to use safely and portably.
> What have I missed?
It's possible to use intrusive_ptr safely and portably if you already have
an existing library that provides intrusive reference counting without also
supplying a corresponding pointer type, and one of the goals of
boost::intrusive_ptr is to establish a standard "corresponding pointer type"
for such libraries.
However, you are right that intrusive_ptr doesn't help the implementers of
these libraries to get their reference counting correct, and that it
probably should do that.