Re: naked pointer vs boost::shared_ptr<T>
On Mar 10, 3:58 am, "James Kanze" <james.ka...@gmail.com> wrote:
I'd say that my argument is even stronger in a multithreaded
context. If I'm going to destruct the object, no other thread
should have a pointer to it, or be doing anything where they
might accidentally try to obtain a pointer to it. If another
object happens to have a (temporary) shared_ptr to the object
when I decide to destruct it, I'm hosed. Deferring the
destructor isn't an option, because it means that the destructor
will no longer run in the thread it should and will no longer be
protected by the locks it needs. A real recepe for disaster.
This is not a problem if your destructor doesn't require a specific
thread and does not depend on a particular lock to be held. These
things are imposed by the need to broadcast the "I'm being destroyed"
message, which calls out to foreign code. If you only destroy the
object in the destructor, there is no need for a lock.
This is why weak_ptr only gives you a shared_ptr, to prevent
the owner from destroying the object just after you've
obtained a reference to it.
I understant the rationale. I just don't think it holds up in
actual practice. And it certainly doesn't hold up in this case;
the semantics of the program call for the destruction of the
object, now, and not some indeterminate later.
It works for me.
Obviously, if you can guarantee that no other entity is accessing your
object at the moment, you can destroy it _now_ instead of several
microseconds later. I find the bookkeeping that is required to
guarantee that a waste of my time - if the property doesn't already
hold.
shared_ptr+weak_ptr is not the only concurrency-resilient solution to
the owner/observer problem, of course. Everyone is welcome to come up
with their own schemes. Watch out for deadlock, though.
My experience is that the lower the granularity of the locking,
the higher the risk of deadlock.
On a fairly high level, maybe. It's more to do with "the more
incorrect the granularity, the higher the risk". A low enough level of
lock granularity can eliminate the risk of deadlock. If you never call
a blocking operation while holding a lock, deadlock is impossible.
And a thread safe shared_ptr has a very low granularity.
Usually none. But that has nothing to do with the topic.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]