id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
4616,Race condition in boost::condition::wait(),Jan Horák <jan.horak@…>,Anthony Williams,"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
",Bugs,closed,To Be Determined,thread,Boost Development Trunk,Problem,duplicate,boost::condition::wait  pthread_condition_wait spurious wakeup,