Re: [Boost-users] weak_ptr for intrusive_ptr

From: Alan M. Carroll (amc_at_[hidden])
Date: 2008-08-20 21:58:08

My style is such that I don't share objects between threads because of all the potential for race conditions, so I rarely design with thread safety in mind.

It seems to me there are two issues:
1) From the point of view of the monitor, its pointer is reset "by surprise", an arbitrary amount of time after the object is committed to destruction.
2) The object and the reference count are destructed simultaneously.

I'll look at tweaking intrusive_release_ptr, which knows before the commit to destruct that it's going to happen. Perhaps warning the monitor might work. Additionally, we can detect the existence of weak pointers before destruction by looking at the reference count of the monitor. It might help to know that as well.

At 03:12 PM 8/20/2008, you wrote:
>Thread safety is a problem. Specifically, the race where thread A drops its intrusive_ptr and thread B converts its weak pointer to an intrusive_ptr. Thread B must end up with either NULL or an intrusive_ptr to a still valid object. I'm not seeing an easy way to achieve this using your current technique of using a member or a subobject whose destructor invalidates the weak pointers since once the destructor is entered, it is too late to prevent thread B from running away with its pointer to a zombie. :-)