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

Question

它与这个问题有着松散的联系：std:：thread是否在C11中合并？。虽然问题不同，但意图是一样的：

问题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：比起线程版本，您更喜欢异步版本吗？

其余部分不再是问题的一部分，只是为了澄清：

为什么必须将返回值指定给虚拟变量？

不幸的是，当前的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创建新线程时，不会启动初始化的线程局部变量。也许这不是你想要的

Answer 1

问题一：

我改变了原来的版本，因为原来的版本是错误的。我的印象是Linux线程创建非常便宜，经过测试，我确定新线程中函数调用的开销与普通线程相比是巨大的。创建一个线程来处理函数调用的开销比普通函数调用慢10000倍或更多倍。所以，如果你发出很多小函数调用，线程池可能是个好主意。

很明显，与g一起提供的标准C库没有线程池。但我绝对可以为它们找到一个案例。即使必须将调用推入某种线程间队列的开销，它也可能比启动新线程更便宜。标准允许这样做。

我的意思是，Linux内核人员应该努力使线程创建比目前更便宜。但是，标准C库也应该考虑使用池来实现launch:：async | launch:：deferred。

OP是正确的，使用::std::线程启动线程当然会强制创建一个新线程，而不是使用池中的线程。因此::std::async（::std::启动::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"（英特尔（R）核心（TM）i7-7820HQ CPU@2.90GHz）与苹果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倍左右，在本机OS X上减慢约8倍。

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