Re: [Boost-bugs] [Boost C++ Libraries] #5727: race condition between ~basic_condition_variable() and notify_all()

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5727: race condition between ~basic_condition_variable() and notify_all()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-12-07 21:31:56

#5727: race condition between ~basic_condition_variable() and notify_all()
-------------------------------------+--------------------------------------
  Reporter:  sbear.powell@…          |       Owner:  viboes  
      Type:  Bugs                    |      Status:  assigned
 Milestone:  To Be Determined        |   Component:  thread  
   Version:  Boost 1.46.1            |    Severity:  Problem 
Resolution:                          |    Keywords:          
-------------------------------------+--------------------------------------

Comment (by viboes):

 Replying to [comment:6 sbear.powell@…]:
 > Replying to [comment:5 viboes]:
 > > I think that Boost.Thread can not do any think here. You are sharing
 the variable notifier allocated on the stack between two thread. When the
 function foo returns, the lambda thread will continue using a destroyed
 instance.
 >
 > The only potential fix I can think of on Boost.Thread's side would be to
 lock the {{{condition_variable}}}'s internal mutex in its destructor--that
 way nothing will be destroyed until after {{{notify_all()}}} is out of its
 critical section.

 Maybe I'm wrong, but I think this is out of the philosophy "don't pay for
 what you don't use".

 > >
 > > Note that the same issue will occur with any shared variable.
 > > IMO, it is up to the application to manage with this kind of errors.
 > >
 >
 > Right. Is there any general rule of thumb on thread-safety of
 destructors? What do the other Boost.Thread classes do in regards to that?

 AFAIK no destructor takes care of these kind of thread-safety. If you want
 you can start a thread on the ML so others could give their advice.

 > > Let me know if you share my point of view.
 >
 > Yeah, after some thought I agree with you--it's not really a bug in
 Boost.Thread, unless the rest of the Boost.Thread library keeps
 destructors thread-safe. In the end, it's not so hard to add the second
 mutex, or to just stick {{{t.join()}}} before {{{foo()}}} returns.

 Yes the user has everything to prevent the deadlock.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5727#comment:7>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.