[Boost-bugs] [Boost C++ Libraries] #4616: Race condition in boost::condition::wait()

Subject: [Boost-bugs] [Boost C++ Libraries] #4616: Race condition in boost::condition::wait()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-09-01 10:24:05

#4616: Race condition in boost::condition::wait()
----------------------------------------------------------------------------+
 Reporter:  Jan Horák <jan.horak@…>                                         |       Owner:  anthonyw
     Type:  Bugs                                                            |      Status:  new     
Milestone:  To Be Determined                                                |   Component:  thread  
  Version:  Boost Development Trunk                                         |    Severity:  Problem 
 Keywords:  boost::condition::wait  pthread_condition_wait spurious wakeup  |  
----------------------------------------------------------------------------+
 Hi,
 at the beginning please take in mind that my English is not perfect so
 even it would looks like I'm offensive it is not like that I'm only very
 straight and please stay calm. Thanks a lot.

 Please look at the code below and especially at the bold part of the code
 and please take in mind, that this is the real origin of the problem #706.


 {{{
                 detail::interruption_checker
 check_for_interruption(&cond);
                 {
                     boost::pthread::pthread_mutex_scoped_lock
 internal_lock(&internal_mutex);
                     m.unlock();
                     res=pthread_cond_wait(&cond,&internal_mutex);
                 }
                 m.lock();
 }}}


 As you can see, in the end of the block (end of scope) the 'internal_lock'
 is unlocked and user defined lock named 'm' is not locked yet. It means
 there is a small amount of time when condition happened, but both locks
 are unlocked and this must not happen, because it violates the standard
 (as far as I can see).


 Example:

       1) Thread 1 and 2 are waiting for condition[[BR]]
       2) Condition is signalled[[BR]]
       3) Thread 1 is awaken and get out of the scope[[BR]]
          (so both locks are released now)[[BR]]
       4) And now condition is signalled again[[BR]]
       5) Thread 2 is awaken, get out of the scope and takes 'm.lock()'
 before Thread 1[[BR]]

       Posix 'pthread_cond_wait' quarantees, that whence you return from
 pthread_cond_wait no other thread can get before you.

       The order can be very important in some cases.

       'pthread_cond_wait' it quarantees so boost::condition should
 quarantee it too

       This race condition leads into that there are too many spurious
 wakeups on boost::condition. Lets think about it in big please. Not a 10
 threads or 100 threads, but think about 10 000 threads and what it will do
 when there will be so much spurious wakeups.

      Evaluate the predicate can take some time so so much spurious wakeups
 leads into serious problems.


 Proposed fix:

 So, 'm.lock()' should be in the end of the 'pthread_cond_wait' block to be
 the lock taken before the internal lock is released.



 So, thanks for reading (at least) and have a nice day, Jan

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