[Boost-users] shared_ptr race condition

From: Sharon Paisner (spaisner_at_[hidden])
Date: 2004-10-22 08:44:53

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_at_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_at_domain" ) );
14      UriPtr uriComplete( new Uri( "sip:complete_at_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