为什么 boost::barrier 等待不是中断点？答案

【问题标题】：why is boost::barrier wait not an interruption point?为什么 boost::barrier 等待不是中断点？
【发布时间】：2012-07-05 20:17:03
【问题描述】：

当调用 boost::thread Interrupt() 时，使用 boost::barrier wait() 等待的线程不会被中断。例如 http://www.justsoftwaresolutions.co.uk/threading/thread-interruption-in-boost-thread-library.html

这样做有充分的理由吗？

当然我们可以手动放置一个 boost::this_thread::interruption_point() 来解决它。

【问题讨论】：

你在哪里找到第一句话？它不在您链接的页面中。
@Tudor：链接列出了中断点，但不包括boost::barrier::wait()（除非它的实现是在条件变量上调用wait()...）
@Tudor 我没有，我观察到了这种行为，并看到这个页面按预期确认了它，因为 boost:barrier 没有列出。手动添加 interrupt_point 解决了这个问题。但我只是想知道......
可能是因为barrierwait是一个集体操作，需要所有线程互相等待。如果其中一个被打断，那么所有其他的都可能死锁。
这不是真的。 barrier::wait 是根据 condition::wait 实现的，那是一个中断点。

标签： c++ multithreading boost synchronization interrupt-handling

【解决方案1】：

如果在当前线程上设置了中断标志并且行为与挂起线程和调用中断处理程序根本不同，则Boost中断点会抛出异常。 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在处理完一个信号后一直等待。

【讨论】：