为了避免昂贵的线程创建，C ++ 11中的async（launch :: async）是否会使线程池过时？

它与以下问题大致相关：std :: thread是否在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线程的创建非常便宜，经过测试，我确定新线程与普通线程相比，函数调用的开销很大。创建线程以处理函数调用的开销比普通函数调用慢10000倍或更多倍。因此，如果要发出许多小的函数调用，则线程池可能是一个好主意。

很明显，g ++附带的标准C ++库没有线程池。但我绝对可以为他们找到理由。即使有必须通过某种线程间队列将调用推入的开销，它也可能比启动新线程便宜。标准允许这样做。

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

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

问题2：

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

我也不相信强迫您等待销毁之前的返回一定是错误的。我不知道您应该使用该async调用来创建不应返回的“守护程序”线程。而且，如果期望它们返回，则忽略异常是不好的。

问题3：

就个人而言，我喜欢线程启动是明确的。我在可以保证串行访问的孤岛上赋予了很多价值。否则，您最终将处于可变状态，必须始终将一个互斥体包装在某个地方并记住要使用它。

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

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

性能测试

因此，我测试了各种调用方法的性能，并在运行Fedora 29（使用clang版本7.0.1和libc ++（不是libstdc ++））的8核（AMD Ryzen 7 2700X）系统上得出了这些数字：

   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                                      

Apple LLVM version 10.0.0 (clang-1000.10.44.4)在OSX 10.13.6下的MacBook Pro 15英寸（英特尔®酷睿i7-7820HQ CPU @ 2.90GHz）上，它是本地的，我得到以下信息：

   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倍。

我创建了一个Bitbucket项目，其中保存了用于性能测试的代码。可以在这里找到：https : //bitbucket.org/omnifarious/launch_thread_performance