C++11 中的 async(launch::async) 是不是会使线程池过时以避免昂贵的线程创建？

Posted 2023-02-19

【中文标题】C++11 中的 async(launch::async) 是不是会使线程池过时以避免昂贵的线程创建？

【英文标题】：Does async(launch::async) in C++11 make thread pools obsolete for avoiding expensive thread creation?C++11 中的 async(launch::async) 是否会使线程池过时以避免昂贵的线程创建？

【发布时间】：2012-12-30 08:31:43

【问题描述】：

它与这个问题松散相关：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 产生的线程中，我有点不清楚，因为线程可以被重用。据我了解，线程局部变量不保证会被重置，但我可能弄错了。 另一方面，如果您确实需要，使用您自己的（固定大小）线程池可以让您完全控制。

【问题讨论】：

“但是，std::async(launch::async) 似乎有更高的机会被合并。”不，我相信它的std::async(launch::async | launch::deferred) 可能会被合并。只需launch::async，无论其他任务正在运行，该任务都应该在新线程上启动。使用launch::async | launch::deferred 策略，实现可以选择哪个策略，但更重要的是它可以延迟选择哪个策略。也就是说，它可以等到线程池中的某个线程可用，然后再选择异步策略。

据我所知，只有 VC++ 使用std::async() 的线程池。我仍然很想知道它们如何在线程池中支持非平凡的 thread_local 析构函数。

@bames53 我浏览了 gcc 4.7.2 附带的 libstdc++，发现如果启动策略不是 exactly launch::async，那么它会将其视为只有 launch::deferred 并且从不异步执行它 - 所以实际上，该版本的 libstdc++“选择”始终使用 deferred，除非另有强制。

@doug65536 关于 thread_local 析构函数，我的观点是，在使用线程池时，线程退出时的破坏并不完全正确。根据规范，当一个任务异步运行时，它“就像在一个新线程上一样”运行，这意味着每个异步任务都有自己的 thread_local 对象。基于线程池的实现必须特别注意确保共享相同支持线程的任务仍然表现得好像它们有自己的 thread_local 对象。考虑这个程序：pastebin.com/9nWUT40h

@bames53 在我看来，在规范中使用“好像在新线程上”是一个巨大错误。 std::async 对于性能来说可能是一件美妙的事情——它可能是标准的短期任务执行系统，自然地由线程池支持。现在，它只是一个 std::thread 加上一些废话，以使线程函数能够返回一个值。哦，他们添加了与std::function 的工作完全重叠的冗余“延迟”功能。

【参考方案1】：

问题 1：

我改变了原来的这个，因为原来的错误。我的印象是Linux thread creation was very cheap，经过测试，我确定新线程中的函数调用开销与普通线程相比是巨大的。创建线程来处理函数调用的开销比普通函数调用慢 10000 倍或更多倍。因此，如果您要发出大量小函数调用，线程池可能是个好主意。

很明显，g++ 附带的标准 C++ 库没有线程池。但我绝对可以为他们看到一个案例。即使不得不通过某种线程间队列推动调用的开销，它也可能比启动一个新线程便宜。而标准允许这样做。

恕我直言，Linux 内核人员应该致力于让线程创建比现在更便宜。但是，标准C++库也应该考虑使用pool来实现launch::async | launch::deferred。

而且 OP 是正确的，使用 ::std::thread 启动线程当然会强制创建一个新线程，而不是使用池中的一个。所以::std::async(::std::launch::async, ...)是首选。

问题 2：

是的，基本上这个'隐式'启动一个线程。但实际上，发生的事情仍然很明显。所以我真的不认为隐含这个词是一个特别好的词。

我也不认为强迫您在销毁之前等待归还一定是错误的。我不知道您应该使用async 调用来创建预期不会返回的“守护进程”线程。如果他们预计会返回，那么忽略异常是不行的。

问题 3：

就个人而言，我喜欢线程启动是明确的。我非常看重可以保证串行访问的岛屿。否则你最终会得到一个可变状态，你总是必须在某个地方包装一个互斥锁并记住使用它。

与“未来”模型相比，我更喜欢工作队列模型，因为周围存在“串行孤岛”，因此您可以更有效地处理可变状态。

但实际上，这完全取决于你在做什么。

性能测试

因此，我测试了各种调用方法的性能，并在运行 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）和 OSX 10.13.6 下的 Apple LLVM version 10.0.0 (clang-1000.10.44.4) 上，我得到了这个：

   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 倍左右的速度，在本机 OS X 上减慢大约 8 倍。

我创建了一个 OSDN 室来保存我用于性能测试的代码。可以在这里找到：https://osdn.net/users/omnifarious/pf/launch_thread_performance/

【讨论】：

我同意工作队列模型，但是这需要一个“管道”模型，它可能不适用于所有并发访问的使用。

在我看来，表达式模板（用于运算符）可用于组合结果，对于函数调用，我猜你需要一个 call 方法，但由于重载，它可能稍微困难一点。

“非常便宜”与您的体验有关。我发现 Linux 线程创建开销对于我的使用来说是大量。

在第一部分中，您有点低估了要创建威胁需要做多少事情，而调用函数需要做多少事情。函数调用和返回是一些 CPU 指令，它们操作堆栈顶部的几个字节。威胁创建意味着：1. 分配堆栈，2. 执行系统调用，3. 在内核中创建数据结构并将它们链接起来，沿途抓住锁，4. 等待调度程序执行线程，5. 切换线程的上下文。这些步骤中的每一个都比最复杂的函数调用花费多更长的时间。

@Omnifarious 一个函数调用大约需要 20 个 CPU 周期（您测量的更少，因为一些开销隐藏在您的测试工具后面）。内存分配很容易占用 200 个 CPU 周期。一个系统调用不小于大约 200ns。抢锁是威胁间通信，需要在内核中执行，预计大约在微秒左右。而且我还没有开始设置页表或刷新 TLB 的开销。如果专用硬件允许更快地创建线程，那是因为硬件已针对此进行了优化，而 X86 CPU 则没有。