shared_ptr race condition
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. 1 int main( int argc, char *argv[] ) 2 { 3 AAFramework aa; 4 CallPtr call( new Call( aa ) ); 5 6 UriPtr callee( new Uri( "sip:name@domain" ) ); 7 call->setInitialCallee( callee ); 8 9 assert( call->getInitialCallee() == callee ); 10 11 TagPtr tag( new Tag() ); 12 CallIdPtr callId( new CallId() ); 13 UriPtr contact( new Uri( "sip:contact@domain" ) ); 14 UriPtr uriComplete( new Uri( "sip:complete@domain" ) ); 15 16 DialogPtr newDialog = call->createDialog( DT_CALLEE, tag, callId, contact, uriComplete ); 17 assert( call->getDialog( DT_CALLEE ) == newDialog ); 18 19 return EXIT_SUCCESS; 20 } one of the strangest aspects of this problem is that it occurs on some machines, but not others, and I have yet to determine the difference between the systems on which it works and the systems on which it doesn't work. Boost's use of so much inline code makes it very difficult to debug the program. in case it helps any, I'm using boost-1.31 and gcc-3.4.2. thanks, Sharon
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.
participants (2)
-
Peter Dimov
-
Sharon Paisner