[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 |
 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.


 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).


       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.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:04 UTC