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

以boost :: barrier等待的线程wait（）在boost :: thread中断（）被调用时不会中断。例如 http://www.justsoftwaresolutions.co.uk/threading/thread-interruption-in-boost-thread-library.html 为什么boost :: barrier等待不是中断点？

有没有很好的理由呢？

当然，我们可以手动放置一个boost :: this_thread :: interruption_point（）来处理它。

来源

2012-07-05 AlexS

你究竟在哪里找到第一句话？它不在您链接的页面中。 – Tudor 2012-07-05 20:21:49

@Tudor：链接列出了中断点，并且不包括'boost :: barrier :: wait（）'（除非它的实现正在调用条件变量的wait（）...） – 2012-07-05 20:23:25

@都铎王朝我没有，我观察到的行为，并看到这一页确认，如预期，事实上，提升：屏障没有列出。手动添加中断点解决了问题。但我只是想知道...... – AlexS 2012-07-05 20:24:36

如果在当前线程上设置了中断标志，并且行为与暂停线程和调用中断处理程序有本质区别，则Boost中断点会引发异常。 boost中的锁都不是中断点，它遵循pthread锁的行为;当pthread锁在等待时被信号处理程序中断，当处理程序完成时它会一直等待。以同样的方式，如果您将升压线程标记为中断，则boost::mutex::lock()或boost::barrier::wait()将继续等待。

另一件事是，如果允许barrier::wait()提前返回而不获取锁，则必须在抛出异常之前从等待屏障的线程池中取消注册当前线程，这会使实现更复杂。它也允许锁定/等待方法返回而不需要获取锁定，这也会让你的代码更复杂。

一般来说，我认为这只是一个设计选择。

如果你看一下是断点方法，你会看到他们通常注定要睡觉sleep和pthread_cond_wait也正在通过信号终止的时间较长（boost::this_thread::sleep()，boost::condition_variable_any::wait()）及其conterparts。虽然这里有一个例外是boost::thread::join()，这是一个中断点，而pthread_join在处理完一个信号后仍然在等待。

来源

2012-07-06 00:09:13 tomasz

谢谢，有道理。 – AlexS 2012-07-06 11:07:04

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

回答

相关问题