std :: async有什么问题？
从C ++ And Beyond开始，我听到了有关std::async问题。 我有两个问题：
对于初级开发人员，在使用std::async时，有什么规则可以避免？
此视频中出现了哪些问题？ 他们是否与这篇文章有关？
有几个问题：
没有启动策略的std::async允许运行时库选择是启动一个新线程还是在将来调用get()或wait()的线程中运行任务。 正如Herb所说，这种情况很可能要使用。 问题在于，这会让它向运行时库的QoI开放，以便正确地获取线程数量，并且您不知道该任务是否有自己的线程，因此使用线程局部变量可能会产生问题。 据我所知，这正是斯科特所关心的。
在明确调用get()或wait()之前，使用std::launch::deferred并不会真正运行任务。 这几乎不是你想要的，所以不要这样做。
使用std::launch::async启动一个新线程。 如果你不记录你有多少线程，这可能导致运行的线程太多。
Herb关注std::future析构函数的行为，它应该等待任务完成，尽管MSVC2012有一个不等待的错误。
对于初级开发者，我会建议：
std::async 。 我无法对使用默认策略的建议有更多的不同意见。
如果您经历了设计独立计算单元的痛苦，那么您可能不希望它们按顺序运行，而有六个CPU旋转拇指，这可能会“合法”发生，这取决于您选择的编译器。
默认行为的隐含假设是一些复杂的线程池机制将优化任务放置（可能会让一些在调用者的CPU上按顺序运行），但这纯粹是幻想，因为没有指定C ++运行时必须执行的操作无论如何，超出编译器运行时的范围）。
这看起来更像是设计给我的未定义行为。
一个名为“async”的类应该启动异步执行单元，除非有一些明确的和确定性的行为参数告诉它。
坦率地说，除了调试目的外，我看不到launch::deferred的用法，除非你打算编写自己的伪调度器，在这种情况下，你最好使用纯线程。
所以我的建议是指定launch::async当使用async ，（告诉编译器像“嘿，我想要一些异步任务，但实际上异步，好吗？”），而不是使用async可言，如果你只是想顺序执行任务。
如果您遇到异步任务时遇到麻烦，可以方便地使用deferred策略来更轻松地进行调试，但这就是关于它的原因。
上一篇: What is the issue with std::async?
下一篇: std::atomic bool or Normal global bool is good in single thread?