Effective Modern C++ 条款36 如果异步执行是必需的，指定std::launch::async策略

如果异步执行是必需的，指定std::launch::async策略

当你调用std::async来执行一个函数（或一个可执行对象）时，你通常希望函数是异步执行的。但你没有要求std::async必须这样做，函数是根据std::async的发射策略（launch policy）来执行的。有两个标准策略，每个都是通过std::launch局部枚举（scoped enum， 看条款10）来表示。假设一个函数

f

要传递给std::launch执行，

std::launch::async发射策略意味着函数

f

必须异步执行，即在另一线程执行。

std::launch::deferred发射策略意味着函数

f

可能只会在——std::async返回的future对象调用get或wait时——执行。那就是，执行会推迟到其中一个调用发生。当调用get或wait时，

f

会同步执行，即，调用者会阻塞直到

f

运行结束。如果get或wait没有被调用，

f

就绝对不会执行。

可能很奇怪，std::async的默认发射策略——它的默认策略是你不能显式指定的——不是两者其中的一种，相反，是两者进行或运算。下面两个函数完全是相同的意思：

auto fut1 = std::async(f);       // 使用默认发射策略执行f

auto fut2 = std::async(std::launch::async |     // 使用async或deferred执行f
std::launch::deferred
f);

默认的发射策略允许异步或同步执行函数

f

，就如条款35指出，这个灵活性让std::async与标准库的线程管理组件一起承担线程创建和销毁、避免过载、负责均衡的责任。这让用std::async进行并发编程变得很方便。

但用std::async的默认发射策略会有一些有趣的含义。这语句给定一个线程t执行

f

，

auto fut = std::async(f);        // 使用默认发射模式执行f

没有办法预知函数

f

是否会和线程t并发执行，因为

f

可能会被调度为推迟执行。

没有办法预知函数

f

是否运行在——与调用get或wait函数的线程不同的——线程。如果那个线程是t，这句话的含义是没有办法预知

f

是否会运行在与t不同的线程。

可能没有办法预知函数

f

是否执行完全，因为没有办法保证

fut

会调用get或wait。

默认发射策略的调度灵活性经常会混淆使用thread_local变量，这意味着如果

f

写或读这种线程本地存储(Thread Local Storage，TLS)，预知取到哪个线程的本地变量是不可能的：

auto fut = std::async(f);         // f使用的线程本地存储变量可能是独立的线程的，
// 也可能是fut调用get或wait的线程的

它也影响了基于wait循环中的超时情况，因为对一个推迟（策略为deferred）的任务（看条款35）调用wait_for或者wait_until会返回值std::launch::deferred。这意味着下面的循环，看起来最终会停止，但是，实际上可能会一直运行：

using namespace std::literals;         // 对于C++14的持续时间后缀，请看条款34

void f()           // f睡眠1秒后返回
{
std::this_thread::sleep_for(1s);
}

auto fut = std::async(f);          // （概念上）异步执行f

while(fut.wait_for(100ms) !=         // 循环直到f执行结束
std::future_status::ready)     // 但这可能永远不会发生
{
...
}

如果

f

与调用std::async的线程并发执行（即，使用std::launch::async发射策略），这里就没有问题（假设

f

能结束执行，不会一直死循环）。但如果

f

被推迟（deferred），

fut.wait_for

将总是返回std::future_status::deferred。那永远也不会等于std::future_status::ready，所以循环永远不会终止。

这种bug在开发或单元测试中很容易被忽略，因为它只会在机器负载很重时才会显现。在机器过载（oversubscription）或线程消耗完的状况下，任务很可能会被推迟（如果使用的是默认发射策略）。总之，如果不是过载或者线程耗尽，运行系统没有理由不调度任务并发执行。

解决办法很简单：检查std::async返回的future，看它是否把任务推迟，然后呢，如果真的是那样，就避免进入基于超时的循环。不幸的是，没有办法直接询问future的任务是否被推迟。取而代之的是，你必须调用一个基于超时的函数——例如wait_for函数。在这种情况下，你不用等待任何事情，你只是要看看返回值是否为std::future_status::deferred，所以请相信这迂回的话语和用0来调用wait_for：

auto fut = std::async(f);       // 如前

if (fut.wait_for(0) == std::future_status::deferred)  // 如果任务被推迟
{
...     // fut使用get或wait来同步调用f
} else {            // 任务没有被推迟
while(fut.wait_for(100ms) !=
std::future_status::ready) {       // 不可能无限循环（假定f会结束）

...    // 任务没有被推迟也没有就绪，所以做一些并发的事情直到任务就绪
}

...        // fut就绪
}

考虑多种因素的结论是，只要满足了下面的条件，以默认发射策略对任务使用std::async能正常工作：

任务不需要与调用get或wait的线程并发执行。

修改哪个线程的thread_local变量都没关系。

要么保证std::async返回的future会调用get或wait，要么你能接受任务可能永远都不执行。

使用wait_for或wait_unitil的代码要考虑到任务推迟的可能性。

如果其中一个条件没有满足，你很可能是想要确保任务能异步执行。而那样做的方法是，当你调用std::async时，把std::launch::async作为第一个参数传递给它：

auto fut = std::async(std::launch::async, f);    // 异步发射f

事实上， 如果有一个函数的行为像std::async那样，但它会自动使用std::launch::async作为发射策略，那样就是一个方便的工作啦！它很容易写出来，棒极了。这是C++11的版本：

template<typename F, typename... Ts>
inline
std::future<typename std::result_of<F(Ts...)>::type>
reallyAsync(F&& f, Ts&&... params)     // 返回异步调用f(param...)的future
{
return std::async(std::launch::async,
std::forward<F>(f),
std::forward<Ts>(params)...);
}

这个函数接收一个可调用对象

f

和零个或多个参数

params

，并且把它们完美转发（看条款25）给std::async，传递std::launch::async作为发射策略。就像std::async那样，它返回一个类型为

f

调用

params

的结果的std::future，决定这个结果很容易，因为std::result_of这个type trait可以把结果给你。

reallyAsync

用起来就像std::async那样：

auto fut = reallyAsync(f);    // 异步执行f，如果std::async抛异常reallyAsync也会抛异常

在C++14中，推断

reallyAsync

返回值类型的能力简化了函数声明：

template<typename F, typename... Ts>
inline
auto
reallyAsync(F&& f, Ts&&... params)          // C++14
{
return std::async(std::launch::async,
std::forward<F>(f),
std::forward<Ts>(params)...);
}

这个版本很清楚地让你知道

reallyAsync

除了使用std::launch::async发射策略调用std::async外，没做任何东西。

总结

需要记住的3点：

std::async的默认发射策略既允许任务异步执行，又允许任务同步执行。

这个灵活性（上一点）导致了使用thread_local变量时的不确定性，它隐含着任务可能不会执行，它还影响了基于超时的wait调用的程序逻辑。

如果异步执行是必需的，指定std::launch::async发射策略。