5e3eca1e   
   From: ulrich.eckhardt@dominolaser.com   
      
   Agents Marlow wrote:   
   > I am getting a nasty error condition from a mutex where it calls   
   > std::terminate. I hope someone here will be able to explain why. The   
   > error message is:   
   >   
   > terminate called after throwing an instance of   
   > 'boost::exception_detail::clone_impl   
   > <   
   >     boost::exception_detail::error_info_injector   
   > >'   
   > what():  boost::lock_error   
      
   std::terminate called after throwing an exception that is not caught, if I'm   
   guessing right. I'd attach a debugger and see what is causing the problem.   
      
      
   > I read somewhere that the fix for this is to use a recursive mutex.   
      
   No, that suggestion without any analysis of the problem is surely wrong.   
      
      
   > Here is my situation: I have a parent thread that owns an object that   
   > contains a concurrent queue. This object is set up from info in a   
   > config file. Let us call this object a config object. Under certain   
   > conditions the parent thread re-reads the config file and recreates   
   > the config object. The object is managed using a scoped_ptr so when I   
   > need to blow the old object away I create a new config object then do   
   > a reset to that object pointer.   
      
   A scoped_ptr means that the object is not shared, and your statement that   
   your "parent thread"[1] owns it confirms this. Now, the question is why is   
   this thing exclusively owned but somehow shared between threads?   
      
      
   > Here is the concurrent queue object that the config object contains:   
   [snip]   
      
   I've been looking at this, and just a few things:   
   1. I don't see anything locking the mutex recursively, but you should be   
   able to trivially verify that using a debugger.   
   2. As soon as the empty() function returns, the state of the queue could   
   change, so that function is somewhere between dangerous and useless.   
   3. I'm not sure if the condition variable is thread-safe, it might be   
   necessary to lock the associated mutex while signalling it in push().   
   4. timed_wait_and_pop is made unnecessarily long by introducing a temporary   
   to hold a returnvalue. Just return false if the timed_wait() call returns   
   false. YMMV.   
      
      
   > I am not sure how this can be since the config object is only supposed   
   > to be destroyed when there are no child threads left. It is as if a   
   > child thread is still trying to write to the queue when the parent is   
   > trying to destroy it.   
      
   Since you haven't shown any code using that queue, it's impossible to tell.   
   If your suspicion is right, you do have an ownership problem, see the use of   
   scoped_ptr above. Using the right smart pointer (default to shared_ptr)   
   should help remedy this. Try some memory debugger (e.g. valgrind) to see if   
   the object is used after it was destroyed, too.   
      
      
   > If my suspicion is right then I don't think it would be right to   
   > correct this error by changing the concurrent queue to use a recursive   
   > mutex. What do people think?   
      
   Is the mutex locked recursively and is this intended? If not, using a   
   recursive mutex is not a solution, at best it is a workaround. BTW: Using a   
   typedef would have saved you lots of typing and you could change the code to   
   use a recursive mutex with a single-line change. ;)   
      
      
   Good luck!   
      
   Uli   
      
      
   [1] Threads in all systems I know don't share a parent-child relationship.   
   They are peers, even if one started another.   
      
   --   
   Domino Laser GmbH   
   Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932   
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)