[Boost-bugs] [Boost C++ Libraries] #3960: condition_variable::timed_wait() cannot be interrupted

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