Question

Threads waiting with a boost::barrier wait() do not get interrupted when boost::thread Interrupt() is called. e.g.
http://www.justsoftwaresolutions.co.uk/threading/thread-interruption-in-boost-thread-library.html

Is there a good reason for this?

Of course we can manually place a boost::this_thread::interruption_point() to work round it.

Answer 1

Boost interruption points throw exception if interruption flag has been set on current thread and the behaviour is fundamentally different than suspending the thread and calling interruption handler. Neither of locks in boost is an interruption point, which follows the behaviour of pthread locks; when pthread lock is interrupted by signal handler while waiting, it’ll keep waiting when the handler is done. In the same manner, if you mark a boost thread as interrupted, boost::mutex::lock() or boost::barrier::wait() will keep waiting.

The other thing is, if you allowed barrier::wait() to prematurely return without acquiring the lock, you would have to unregister the current thread from the pool of threads waiting for the barrier before throwing an exception, which would make the implementation more complex. It would also allow for lock/wait methods to return without acquiring the lock, which would also make your code more complicated.

Generally, I think it’s simply a design choice.

If you look at methods that are interruption points, you’ll see they’re usually meant to sleep for a longer time (boost::this_thread::sleep(), boost::condition_variable_any::wait()) and their conterparts sleep and pthread_cond_wait are also being terminated by signals. Although an exception here is boost::thread::join(), which is an interruption point, while pthread_join keep waiting after handling a signal.