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

回答

相关问题