Re: Implementation of shared_ptr
James Kanze wrote:
On Jan 29, 9:41 pm, Marcel M?ller <news.5.ma...@spamgourmet.com>
wrote:
But intrusive reference counting is still a extremely
lightweight method for moderate requirements. The runtime
overhead is quite small.
That's one reason to use intrusive reference counting, but it's
not the only one, nor even the most important one.
Non-intrusive reference counting is extremely brittle; with
boost::shared_ptr, for example, you need to take extrodinary
precautions to ensure that you don't end up with two distinct
counters.
Well, I did not have this problem so far, but you are right. You have to
be very careful with non-const pointers to reference counted objects.
Intrusive reference counts are more fault-tolerant. Usually it is not
even required to pass intrusive pointers as function arguments, because
it is quite difficult to pass a pointer to a reference counted object to
a function without holding the ownership at the caller at least until
the end of the statement. But function return values have to be
intrusive pointers in general, because otherwise the reference count can
go temporarily to zero. So you have to be careful too.
(The Boost documentation suggests making all of the
pointers to the object boost::shared_ptr. Which is fine, but
the compilers I use don't collaborate---this isn't a
boost::shared_ptr.)
What's wrong with your compiler?
That's for the cases where reference counting is appropriate, of
course. which aren't all that frequent to begin with.
Hmm.
OK the interlocked access to the reference counter does not
scale that good on x86/x64 SMP machines, but this is more
related to x86/x64 than to the method.
The interlocked access is necessary regardless of the strategy.
Of course, but on x86 any interlocked instruction is always a full
membar. This is not required in this case.
On the other hand, I find that when an object is being passed
between threads, auto_ptr is more appropriate: once the second
thread has access, you don't want to allow access from the first
thread.
I would like to say that the most frequent use for reference counts are
thread-safe objects. Because as long as the object is thread local or
dedicated to exactly one thread at one time, there is simply no need for
reference counts. But if the object has (some) thread-safe methods, it
makes sense, that more than one thread holds an active reference to the
object.
Of course, there may be single threaded applications with reference
counting too. E.g. if you have worker queues with items that refer to
some business objects. (Maybe simply the GUI message queue).
I often use reference counting in conjunction with a global, type
specific instance repository (in fact a template class with some static
members). The repository keeps track of all objects of a certain type
(or base type) with respect to their key. However, to cleanup the
repository intrusive reference counting is helpful.
Marcel