调用 boost::thread Interrupt() 时,使用 boost::barrier wait() 等待的线程不会被中断。例如 http://www.justsoftwaresolutions.co.uk/threading/thread-interruption-in-boost-thread-library.html
这有充分的理由吗?
当然,我们可以手动放置一个 boost::this_thread::interruption_point() 来解决它。
调用 boost::thread Interrupt() 时,使用 boost::barrier wait() 等待的线程不会被中断。例如 http://www.justsoftwaresolutions.co.uk/threading/thread-interruption-in-boost-thread-library.html
这有充分的理由吗?
当然,我们可以手动放置一个 boost::this_thread::interruption_point() 来解决它。
如果在当前线程上设置了中断标志并且行为与挂起线程和调用中断处理程序根本不同,则提升中断点会抛出异常。boost 中的任何一个锁都不是中断点,它遵循 pthread 锁的行为;当 pthread 锁在等待期间被信号处理程序中断时,它会在处理程序完成后继续等待。同样的方式,如果你将一个 boost 线程标记为中断,boost::mutex::lock()
或者boost::barrier::wait()
会一直等待。
另一件事是,如果您允许barrier::wait()
在未获取锁的情况下提前返回,则必须在抛出异常之前从等待屏障的线程池中注销当前线程,这会使实现更加复杂。它还允许锁定/等待方法在不获取锁定的情况下返回,这也会使您的代码更加复杂。
一般来说,我认为这只是一个设计选择。
如果您查看作为中断点的方法,您会发现它们通常意味着要休眠更长的时间 ( boost::this_thread::sleep()
, boost::condition_variable_any::wait()
) 及其对应部分sleep
,并且pthread_cond_wait
也会被信号终止。虽然这里有一个例外boost::thread::join()
,它是一个中断点,但pthread_join
在处理完信号后继续等待。