C++ fork/std :: thread和boost :: timed_join

我有一個程序正在分析一些文件（最多10000個）。平臺是帶有unix操作系統的AMD64。語言是C++。C++ fork/std :: thread和boost :: timed_join

該程序目前正在爲每個文件分配主進程（直到達到限制，然後等待，直到孩子完成）。孩子正在啓動boost :: thread來執行分析功能，然後在它創建的boost :: thread上執行boost :: timed_join。

所以，我現在有一些問題。

用一個更輕量級的選項替換叉是否合理？我不確定這可能會帶來多少性能/內存增益，我在某處讀到了stackoverflow上的那個fork在unix上並不昂貴。
我將如何執行殺死正在進行分析的線程？開始2線程，一個執行分析，另一個正在等待，如果第一個在一段時間後沒有完成，第二個是殺死第一個？有沒有更優雅的方式來做到這一點？如果這是選擇的選項，我該如何殺死另一個線程？獲得本地句柄，然後pthread_kill（）？
如果保持fork機制是可建議的：我想過用std :: threads替換boost :: threads，我將如何替換boost :: timed_join？讓孩子進入睡眠狀態一段時間，然後殺死線程將是一種做法，但如果線程在時間結束之前完成（這將始終發生），那麼孩子仍然會睡覺，直到時間結束 - >開銷。

任何意見將不勝感激！

來源

2014-06-11 Ilendir

創建新進程比創建新線程更重量級，因此不會這樣做會在已用資源方面帶來優勢。另一方面，如果分叉進程崩潰，那麼其他進程不受影響，這可能不是線程的情況。 – Ashalynd

今天我遇到AFIO（docs,code）。這是一個構建在ASIO和Boost.Thread上的有抱負的Boost候選人。

用afio是一個線性擴展，批量，延伸ASIO和Boost.Thread環連接，異步閉合執行引擎專門爲便攜式異步文件I/O實現庫。

這可能會簡化異步文件處理。

請注意，這不會分叉其他操作系統進程，而是改爲使用線程或ASIO Proactor線程類構造。它可能會消耗更少的系統資源，但更易於崩潰（如@Ashalynd所述）

來源

2014-06-12 12:05:19

我作爲Boost.AFIO的作者不得不不同意這個建議:)如果你想盡可能快地處理10,000個文件，我實際上建議你爲每個文件啓動一個線程，該文件打開文件，將其映射到內存中並讀取它來自內存映射（如果文件大於64Kb）。線程在任何最新的操作系統上都非常便宜，並且內存映射爲內核提供了最大的自由度來充分利用內存和存儲I/O隊列深度。當然，AFIO可以做到以上所有的事情，但這可能是爲了滿足您的需求而過度使用 - 直接編寫並不難。 –

我還會添加一個Boost.Thread維護者，你真的想避免混合線程和叉子。選擇一個或另一個。混合它們爲Boost.Thread引入了很多複雜性，即性能消耗開銷。現在叉子的速度相當快，但線程有更多可預測的複雜性和開銷。叉雖然非常方便。最後，在C++ 11 STL中應該有一個線程timed_join函數，所以只需打開工具鏈上的C++ 11即可。 –

C++ fork/std :: thread和boost :: timed_join

回答

相關問題