https://svn.boost.org/trac10/ticket/322 <pre class="wiki">Hello - I've been working through the Boost.Threads example code, I'm new to the library, but i think i found a bug in the monitor.cpp example (boost_1_31_0/libs/thread/example/monitor.cpp) . When run using a recursive_mutex, the program hangs more often than not. It appears that the cuplrits are the calls to cond.wait(lk). For the recursive_mutex case, it appears that in some circumstances, these fall through without actually waiting for a change in the state of the lock lk. Attached is an example which is somewhat simpler that the one in monitor.cpp, but yields the same problem. Note that I'm compiling on a redhat ws3 system, with: Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42) and linking against libboost_thread-gcc-mt.so Typical output as given is: sent 100, received 100 sender waits 99, receiver waits 49944 I.e. close to 50k calls to cond.wait() in the receiver thread) When recompiling with "recursive_mutex" replaced by "mutex", the number of waits is on the order of the number of receives (i.e. in the range 0-100) Any help/insight is appreciated. Regards, Bill Moser billm@ll.mit.edu </pre> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/322 Trac 1.4.3 Roland Schwarz Fri, 14 Apr 2006 14:38:14 GMT https://svn.boost.org/trac10/ticket/322#comment:1 https://svn.boost.org/trac10/ticket/322#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">assigned</span> → <span class="trac-field-new">closed</span> </li> </ul> <pre class="wiki">Logged In: YES user_id=541730 Can't tell what the problem was. I tested with boost RC_1_34 on linux with gcc 4.0.3 and could not observe the described behaviour. </pre> Ticket