以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（）來處理它。
如果在當前線程上設置了中斷標誌，並且行爲與暫停線程和調用中斷處理程序有本質區別，則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在處理完一個信號後仍然在等待。
謝謝，有道理。 – AlexS 2012-07-06 11:07:04
你究竟在哪裏找到第一句話？它不在您鏈接的頁面中。 – 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