条款38：对变化多端的线程句柄析构函数行为保持关注

条款37解释过，可联结的线程对应着一个底层系统执行线程，未推迟任务（参见条款36）的期值和系统线程有类似关系。这么一来，std::thread型别对象和期值对象都可以视作系统线程的句柄。

从这个视角来看，std::thread对象和期值对象的析构函数表现出如此不同的行为值得深思。正如条款37所提及的，针对可联结的std::thread型别对象实施析构会导致程序终止，因为另外两个显而易见的选择（隐式join和隐式detach）都被认为是更糟糕的选择。而期待的析构函数呢，有时候行为像是执行了一次隐式join,有时候行为像是执行了一次隐式detash，有时候行为像是二者都没有执行。它从不会导致程序终止。这套线程句柄行为的大杂烩，值得我们仔细品鉴一番。

我们的观察从这里开始：期值位于信道的一端，被调方把结果通过该信道传输给调用方。被调方（通常以异步方式运行）把其计算所得的结果写入信道（通常经由一个std::promise型别对象），而调用方则使用一个期值来读取该结果。你可以把这个过程想成下图，虚线箭头代表着从被调方向调用方的信息流：

但被调方的结果要存储在哪里呢？在调用方唤起对应期值的get之前，被调方可能已经执行完毕，因此结果不会存储在被调用方的std::promise型别对象里。那个对象，对于被调方来说就是个局部量，在被调方结束后会实施析构。

该结果也不能存储在调用方的期值中，因为（出于其他种种原因）可能会从std::future型别对象出发创建std::shared_future型别对象（因此把被调方结果的所有权从std::future型别对象转移至std::shared_future型别对象），而后者可能会在原始的std::future析构之后复制多次。如果被调方的结果型别不都是可复制的（即只移型别），而该结果至少生存期要延至和最后一个指涉到它的期值一样长。这么多个对应同一结果的期值中的哪一个，应该包含该结果呢？

既然与被调方相关联的对象和与调用方相关联的对象都不适合作为被调方结果的存储之所，那就只能将该结果存储在位于两者外部的某个位置。这个位置称为共享状态。共享状态通常使用堆上的对象来表示，但是其型别、接口和实现标准皆未指定。标准库作者可以自由地用他们喜好的方法去实现共享状态。

我们可以把调用方、被调用方和共享状态之间的关系使用下图来表示，虚线箭头仍然表示着信息流：

共享状态的存在很重要，因为期值析构函数的行为（这也是本条款的议题）是由与其关联的共享状态决定的。具体来说就是：

指涉到经由std::async启动的未推迟任务的共享状态的最后一个期值会保持阻塞，直至该任务结束。本质上，这样一个期值的析构函数是对底层异步执行任务的线程实施了一次隐式join.
其他所有期值对象的析构函数只仅仅将期值对象析构就结束了。对于底层异步运行的任务，这样做类似于对线程实施了一次隐式detach.对于那些被推迟任务而言，如果这一期值是最后一个，也就意味着被推迟的任务将不会有机会运行了。

这些规则听上去复杂，其实不然，我们真正需要关心的，是一个平凡的"常规"行为外加一个不甚常见的例外而已。常规行为是指期值的析构函数仅会析构期值对象。就这样。它不会针对任何东西实施join,也不会从任何东西实施detach，也不会运行任何东西。它仅会析构期值的成员变量（好吧，实际上，它还多做了一件事。它针对共享状态里的引用计数实施了一次自减。该共享状态由指涉到它的期值和被调方的std::promise共同操作。该引用计数使得库能知道何时可以析构共享状态。关于引用计数的一般材料，参见条款19）。

而相对于正常行为的那个例外，只有在期值满足以下全部条件时才会发挥作用：

期值所指涉的共享状态是由于调用了std::async才创建的
该任务的启动策略是std::launch::async。这既可能是运行时系统的选择，也可能是在调用std::async时指定的。
该期值是指涉到该共享状态的最后一个期值，对于std::future型别对象而言，这一点总是成立。而对于std::shared_future型别对象而言，在析构时如果不是最后一个指涉到共享状态的期值，则它会遵循常规行为准则（即仅析构其成员变量）

只有当所有条件都满足，期值的析构函数才会表现出特别行为。而行为的具体表现为阻塞直到异步运行的任务结束。从效果来看，这相当于针对正在运行的std::async所创建的任务的线程实施了一次隐式join。

经常会有人把这个例外和常规期望析构函数行为的差异说成是“来自std::async的期值会在其析构函数里被阻塞。”如果只是最粗略的近似，这种说法也不为错，但有时候你需要比最粗略的近似了解得更深一步。而现在，你已经知道了全面的真相。

抑或你的疑问又并不同，可能会是“为什么要为从std::async出发启动的非推迟任务相关联的共享状态专门制定一条规则？”问得合理。根据我所知道的，标准委员会想要避免隐式detach相关的问题（参见条款37），但是他们又不想简单粗暴地让程序终止了事（他们针对可联结线程就是这样做的，参见条款37），所以妥协结果就是实施一次隐式join.这个决定并非没有争议，委员会也曾认真讨论过要在C++14中舍弃这样的行为，但是最后没有做出改变，所以期值析构函数的行为在C++11和C++14中是保持了一致的。

期值的API没有提供任何方法判断其指涉的共享状态是否诞生于std::async的调用，所以给定任意期值对象的前提下，它不可能知道自己是否会在析构函数中阻塞到异步任务执行结束。这个事实暗示着一些意味深长的推论：

//该容器的析构函数可能会在其析构函数中阻塞，
//因为它所持有的期值中可能会有一个或多个
//指涉到经由std::async启动未推迟任务所产生的共享状态
std::vector<std::future<void>> futs;   //关于std::future<void>参见条款39

class Widget{
public:                              //Widget型别对象可能会在其析构函数中阻塞
    ...

private:
    std::shared_futrue<double> fut;
};

当然，如果有办法判定给定的期值不满足触发特殊析构行为的条件（例如，通过分析程序逻辑），即可断定该期值不会阻塞在其析构函数中。例如，只有因std::async调用而出现的共享状态才够格去展示特别行为，但是还有其它方法可以创建出共享状态。其中一个方法就是运用std::packaged_task,std::packaged_task型别对象会准备一个函数（或其他可调用的对象）以供异步执行，手法是将它加上一层包装，把其结果置入共享状态。而指涉到该共享状态的期值则可以经由std::packaged_task的get_future函数得到：

int calcValue();  //待运行的函数

std::packaged_task<int()> pt(calcValue);  //给calcValue加上包装使之能以异步方式运行

auto fut = pt.get_future();  //取得pt的期值

此时此刻，我们已知期值对象fut没有指涉到由std::async调用产生的共享状态，所以它的析构函数将表现出常规行为。

std::packaged_task型别对象pt一经创建，就会运行在线程之上（它也可以经由std::async的调用而运行，但是如果你要用std::async运行任务，就没有很好的理由再去创建什么std::packaged_task型别对象，因为std::async能够在调度任务执行之前就做到std::packaged_task能够做到的任何事情）。

std::packaged_task不能复制，所以欲将pt传递给std::thread的构造函数就一定要将它强制转型有右值（经由std::move,参加条款23）：

std::thread t(std::move(pt));  //在t之上运行pt

此例让我们能够隐约看出一些期值的常规析构行为，但如果把这些语句都放在同一代码块中，就可以看得更加清楚：

{                        //代码块开始
    std::packaged_task<int()> pt(calcValue);
    auto fut = pt.get_future();
    std::thread t(std::move(pt));

    ...                  //见下

}                        //代码块结束

这里最值得探讨的代码是“...”部分，它位于t创建之后、代码块结束之前。值得探讨的是，在‘...’中t的命运如何。基本存在三种可能：