condition_variable::timed_wait() cannot be interrupted

[anonymous]

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?

[gyula.gubacsi@…]

Partial code

[gyula.gubacsi@…]

Sorry, that wasn't a timed_wait() but a wait().

[viboes]

The difference is that as far as you have a timeout you will be wake up and the the interruption check point will be done. You can pool with a timed_wait with the granularity you want to achieve the behavior you want. Other than polling I don't see any other solution. And make the wait function pool on a default granularity will penalize the users that don't need to interrupt the thread.

It is also true that the documentation let think that wait will be interrupted if a interrupts is signaled, but it does this only before and after the underlying wait.

"The following functions are interruption points, which will throw boost::thread_interrupted if interruption (BEFORE CALLING) is enabled for the current thread, and interruption is requested for the current thread: "

Maybe the library could add a interruptible wait with a specific granularity.

[viboes]

See also ticket:2330 which gives an implementation that doesn't seems too expensive.

[Anthony Williams]

Duplicate of 2330