Subject: [Boost-bugs] [Boost C++ Libraries] #3960: condition_variable::timed_wait() cannot be interrupted
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-02-25 11:20:18
#3960: condition_variable::timed_wait() cannot be interrupted
--------------------------+-------------------------------------------------
Reporter: anonymous | Owner: anthonyw
Type: Bugs | Status: new
Milestone: Boost 1.43.0 | Component: thread
Version: Boost 1.42.0 | Severity: Problem
Keywords: |
--------------------------+-------------------------------------------------
I have a boost::condition_variable::timed_wait() with predicate functor
overload in a thread. It's working fine, if the condition is satisfied it
wakes up, and goes on in the execution. However, I'd like to have an
option to terminate the thread at this waiting-point so I made an
boost::thread::interrupt call on this running thread and before I remove
the object I used the join() method to wait until the thread is really
quits. I did not catch any boost::thread_interruption exception in the
thread after I call the interrupt() method.
I added an exception handler, with a simple return and a break point on
it, but it was never hit. After some struggling I tried to send a
notification to the condition variable (notify_one() method) and
surprisingly it caught the exception mentioned above. This is clearly
different behaviour as it was described in the documentation under the
Thread Management/Predefined Interruption Points section where it claims
that the condition_variable::timed_wait() is supposed to be an
interruption point which means it needs to wake up with calling only the
interrupt() method.
I also think that is a bug not a documentation issue since when I tried to
replace the condition_variable::timed_wait() to a simple
this_thread::sleep() call, the interrupt immediately made the thread wake
up and catch the thread_interruption exception.
I'm not sure is this part involved in the same issue but I had to remove
the coped_lock in the predicate function because it caused a deadlock
there. It is really weird because the one and only other location where
I'm using that mutex is in the wait_for_players() method and that supposed
to run in the same thread. The mutex in the predicate function is maybe
pointless but I saw this solution in many sample code (and makes sense if
the predicate function has a block somewhere inside but in my case it is
not necessary). How is it possible that the predicate function gets the
mutex as it is locked?
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/3960> 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:02 UTC