|
Boost : |
From: SourceForge.net (noreply_at_[hidden])
Date: 2004-11-24 12:00:50
Bugs item #1072605, was opened at 2004-11-24 09:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1072605&group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: condition variables and recursive_mutex
Initial Comment:
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_at_[hidden]
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1072605&group_id=7586
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Boost-bugs mailing list
Boost-bugs_at_[hidden]
https://lists.sourceforge.net/lists/listinfo/boost-bugs
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk