https://svn.boost.org/trac10/ticket/4616 <p> 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. </p> <p> 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 <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/706" title="#706: Bugs: Possible problem with condition releasing (closed: None)">#706</a>. </p> <pre class="wiki"> detail::interruption_checker check_for_interruption(&amp;cond); { boost::pthread::pthread_mutex_scoped_lock internal_lock(&amp;internal_mutex); m.unlock(); res=pthread_cond_wait(&amp;cond,&amp;internal_mutex); } m.lock(); </pre><p> 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). </p> <p> Example: </p> <blockquote> <p> 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 /> </p> <blockquote> <p> (so both locks are released now)<br /> </p> </blockquote> <p> 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 /> </p> </blockquote> <blockquote> <p> Posix 'pthread_cond_wait' quarantees, that whence you return from pthread_cond_wait no other thread can get before you. </p> </blockquote> <blockquote> <p> The order can be very important in some cases. </p> </blockquote> <blockquote> <p> 'pthread_cond_wait' it quarantees so boost::condition should quarantee it too </p> </blockquote> <blockquote> <p> 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. </p> </blockquote> <blockquote> <p> Evaluate the predicate can take some time so so much spurious wakeups leads into serious problems. </p> </blockquote> <p> Proposed fix: </p> <p> 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. </p> <p> So, thanks for reading (at least) and have a nice day, Jan </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/4616 Trac 1.4.3 Anthony Williams Thu, 28 Oct 2010 13:25:50 GMT https://svn.boost.org/trac10/ticket/4616#comment:1 https://svn.boost.org/trac10/ticket/4616#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">duplicate</span> </li> </ul> <p> Duplicate of issue <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/2330" title="#2330: Patches: thread::interrupt() can be lost if condition_variable::wait() in progress (closed: fixed)">#2330</a> </p> Ticket