Re: [Boost-users] shared_ptr race condition

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-10-22 10:50:33

Sharon Paisner wrote:
> I'm having a problem wherein the block of code below hangs at line
> 16. A race condition is being created with the shared_ptrs. The Call
> class contains an std::map of DialogPtrs (where a DialogPtr is just a
> boost::shared_ptr< Dialog
>> ) - is it legal to use a boost::shared_ptr to wrap a class that
>> contains a
> dynamically allocated container like a map?
>
> note: the createDialog() method is write-locked, so that the map
> cannot be accessed by more than one thread at a time.

I see no threads in your code, so it can't be a race condition. My wild 
guess is that one of your translation units has been compiled with 
BOOST_HAS_THREADS and the other was not. This results in shared_ptr trying 
to lock a pthread_mutex that does not exist.

BOOST_HAS_THREADS is supposed to be set automatically by Boost.Config, but 
I'm not sure how well this works with g++ 3.4.x in 1.31.