它与这个问题松散相关:Are std::thread pooled in C++11? .虽然问题不同,但意图是一样的:
问题 1:使用您自己的(或第三方库)线程池来避免昂贵的线程创建是否仍然有意义?
另一个问题的结论是,您不能依赖 std::thread
进行池化(它可能会或可能不会)。但是,std::async(launch::async)
似乎有更高的机会被池化。
它不认为它是由标准强制的,但恕我直言,如果线程创建速度很慢,我希望所有好的 C++11 实现都会使用线程池。只有在创建新线程成本低廉的平台上,我希望它们总是产生一个新线程。
问题2:这只是我的想法,但我没有事实可以证明。我很可能弄错了。这是有根据的猜测吗?
最后,我在这里提供了一些示例代码,首先展示了我认为线程创建可以如何通过 async(launch::async)
来表达:
示例 1:
thread t([]{ f(); });
// ...
t.join();
变成
auto future = async(launch::async, []{ f(); });
// ...
future.wait();
示例 2:触发后忘记线程
thread([]{ f(); }).detach();
变成
// a bit clumsy...
auto dummy = async(launch::async, []{ f(); });
// ... but I hope soon it can be simplified to
async(launch::async, []{ f(); });
问题 3:您更喜欢 async
版本还是 thread
版本?
剩下的不再是问题的一部分,只是为了澄清:
为什么必须将返回值分配给虚拟变量?
不幸的是,当前的 C++11 标准强制您捕获 std::async
的返回值,否则会执行析构函数,该析构函数会阻塞直到操作终止。一些人认为这是标准中的错误(例如,Herb Sutter)。
这个例子来自 cppreference.com很好地说明了这一点:
{
std::async(std::launch::async, []{ f(); });
std::async(std::launch::async, []{ g(); }); // does not run until f() completes
}
另一个澄清:
我知道线程池可能还有其他合法用途,但在这个问题上,我只对避免昂贵的线程创建成本方面感兴趣。
我认为仍然存在线程池非常有用的情况,尤其是当您需要对资源进行更多控制时。 例如,服务器可能决定同时处理固定数量的请求,以保证快速响应时间并增加内存使用的可预测性。线程池应该没问题,在这里。
线程局部变量也可能是您自己的线程池的参数,但我不确定它在实践中是否相关:
- 使用
std::thread
创建一个新线程时不需要初始化线程局部变量。也许这不是你想要的。 - 在
async
产生的线程中,我有点不清楚,因为线程可以被重用。据我了解,线程局部变量不保证会被重置,但我可能弄错了。 - 另一方面,如果您确实需要,使用您自己的(固定大小)线程池可以让您完全控制。
最佳答案
问题 1:
我改变了原来的这个,因为原来的错误。我的印象是Linux thread creation was very cheap经过测试,我确定新线程中的函数调用开销与普通线程相比是巨大的。创建线程来处理函数调用的开销比普通函数调用慢 10000 倍或更多倍。因此,如果您要发出大量小函数调用,线程池可能是个好主意。
很明显,g++ 附带的标准 C++ 库没有线程池。但我绝对可以为他们看到一个案例。即使必须通过某种线程间队列来插入调用的开销,它也可能比启动一个新线程更便宜。而标准允许这样做。
恕我直言,Linux 内核人员应该致力于让线程创建比现在更便宜。但是,标准 C++ 库也应该考虑使用 pool 来实现 launch::async |启动::延迟
.
而且 OP 是正确的,使用 ::std::thread
来启动一个线程当然会强制创建一个新线程,而不是使用池中的一个。所以 ::std::async(::std::launch::async, ...)
是首选。
问题 2:
是的,基本上这个'隐式'启动一个线程。但实际上,发生的事情仍然很明显。所以我真的不认为隐含这个词是一个特别好的词。
我也不认为强制您在销毁之前等待归还一定是错误的。我不知道您应该使用 async
调用来创建不希望返回的“守护进程”线程。如果他们预计会返回,那么忽略异常是不行的。
问题 3:
就个人而言,我喜欢线程启动是明确的。我非常看重可以保证串行访问的岛屿。否则你最终会得到一个可变状态,你总是必须在某个地方包装一个互斥锁并记住使用它。
与“ future ”模型相比,我更喜欢工作队列模型,因为周围存在“串行孤岛”,因此您可以更有效地处理可变状态。
但实际上,这完全取决于你在做什么。
性能测试
所以,我测试了各种调用方法的性能,并在运行 Fedora 29 的 8 核(AMD Ryzen 7 2700X)系统上得出了这些数字,该系统使用 clang 版本 7.0.1 和 libc++(不是 libstdc++)编译:
Do nothing calls per second: 35365257
Empty calls per second: 35210682
New thread calls per second: 62356
Async launch calls per second: 68869
Worker thread calls per second: 970415
原生,在我的 MacBook Pro 15"(Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz)上使用 Apple LLVM 版本 10.0.0 (clang-1000.10.44.4)
在 OSX 10.13.6 下,我明白了:
Do nothing calls per second: 22078079
Empty calls per second: 21847547
New thread calls per second: 43326
Async launch calls per second: 58684
Worker thread calls per second: 2053775
对于工作线程,我启动了一个线程,然后使用无锁队列向另一个线程发送请求,然后等待发回“完成”回复。
“什么都不做”只是为了测试测试工具的开销。
很明显,启动线程的开销是巨大的。即使是带有线程间队列的工作线程,在 VM 中的 Fedora 25 上也会减慢 20 倍左右的速度,在 native OS X 上减慢大约 8 倍。
我创建了一个 OSDN 室来保存我用于性能测试的代码。可以在这里找到:https://osdn.net/users/omnifarious/pf/launch_thread_performance/
关于c++ - C++11 中的 async(launch::async) 是否会使线程池过时以避免昂贵的线程创建?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14351352/