c++ - std::async 参数的生命周期是多少？

Question

似乎通过 std::async 执行的函数的参数共享 future 的生命周期:

#include <iostream>
#include <future>
#include <thread>

struct S
{
    S() {
        std::cout << "S() " << (uintptr_t)this << std::endl;
    }

    S(S&& s) {
        std::cout << "S(&&) " << (uintptr_t)this << std::endl;
    }

    S(const S& s) = delete;

    ~S() {
        std::cout << "~S() " << (uintptr_t)this << std::endl;
    }
};

int main()
{
    {
        std::cout << "enter scope" << std::endl;
        auto func = [](S&& s) {
            std::cout << "func " << (uintptr_t)&s << std::endl;
            auto x = S();
        };
        S s;
        auto fut = std::async(std::launch::async, func, std::move(s));
        std::cout << "wait" << std::endl;
        std::this_thread::sleep_for(std::chrono::seconds(5));
        fut.get();
        std::cout << "exit scope" << std::endl;
    }
    return 0;
}

结果:

    enter scope
  ++S() 138054661364        main's variable
  | S(&&) 138054661108 ++   std::async's internal copy
+--+S(&&) 138054659668  |   std::async's internal copy
| | S(&&) 138054922824 +--+ func's argument
+--+~S() 138054659668   | |
  | ~S() 138054661108  ++ |
  | func 138054922824     |
  | S() 138057733700   +  |  local variable
  | ~S() 138057733700  +  |
  | wait                  |
  | exit scope            |
  | ~S() 138054922824  +--+
  ++~S() 138054661364

看起来底层实现 (MSVS 2015 U3) 在地址 138054922824 处创建了参数的最终版本，但在 future 被销毁之前不会销毁它。

感觉这违反了 RAII promise ，因为函数实现可能依赖于退出时调用的参数的析构函数。

这是一个错误还是传递给 std::async 的参数的确切生命周期未知？标准对此有何规定？

Answer 1

用实际答案跟进我之前的评论......

我在 libstdc++ 中遇到过相同的行为。我没有预料到这种行为，它导致了我的代码中的死锁错误(幸运的是，由于等待超时，这只会导致程序终止延迟)。在这种情况下，任务对象(我指的是函数对象 f )在任务完成执行后没有被销毁，只有在未来销毁时才被销毁，但是，任务对象和任何参数很可能实现以相同的方式对待。

std::async 的行为在 [futures.async] 中标准化.

(3.1) If launch​::​async is set in policy, calls INVOKE(DECAY_­COPY(std​::​forward<F>(f)), DECAY_­COPY(std​::​forward<Args>(args))...) ([func.require], [thread.thread.constr]) as if in a new thread of execution represented by a thread object with the calls to DECAY_­COPY() being evaluated in the thread that called async. Any return value is stored as the result in the shared state. Any exception propagated from the execution of INVOKE(DECAY_­COPY(std​::​forward<F>(f)), DECAY_­COPY(std​::​forward<Args>(args))...) is stored as the exceptional result in the shared state. The thread object is stored in the shared state and affects the behavior of any asynchronous return objects that reference that state.

措辞，通过使用DECAY_COPY不命名结果并在 INVOKE 中表达式，强烈建议使用在包含 INVOKE 的完整表达式末尾销毁的临时对象，这发生在新的执行线程上。但是，这还不足以得出结论，参数(的拷贝)不会比函数调用的生命周期超过清理它们所需的处理时间(或任何“合理的延迟”)。它的推理是这样的:基本上，标准要求在执行线程完成时销毁对象。但是，标准不要求执行线程在等待调用或 future 被销毁之前完成:

If the implementation chooses the launch​::​async policy,

(5.3) a call to a waiting function on an asynchronous return object that shares the shared state created by this async call shall block until the associated thread has completed, as if joined, or else time out ([thread.thread.member]);

因此，等待调用可能导致线程完成，然后才等待它完成。在 as-if 规则下，如果代码只是看起来有这种行为，例如公然将任务和/或参数存储在共享状态中，那么代码实际上可能会做更糟糕的事情(注意要立即遵循)。这确实是一个漏洞，IMO。

libstdc++ 的行为使得即使是无条件的 wait()不足以导致任务和参数被破坏——只有一个 get()或毁灭 future 的意志。如果share()被调用，只销毁shared_future的所有拷贝足以造成破坏。这似乎确实是一个错误，因为 wait()肯定被(5.3)中的术语“等待函数”所涵盖，并且不能超时。除此之外，该行为似乎未指明——无论是否是疏忽。

我猜测为什么实现似乎将对象置于共享状态，因为这比标准字面上建议的更容易实现(在目标线程上制作临时拷贝，与 std::async 的调用同步) ).

似乎应该就此提出 LWG 问题。不幸的是，对此的任何修复都可能破坏多个实现的 ABI，因此即使更改已获批准，也可能需要数年时间才能在部署中可靠地修复该行为。

就我个人而言，我得出了一个不幸的结论:std::async有太多的设计和实现问题，以至于它在一个重要的应用程序中几乎毫无用处。我的代码中的上述错误已通过替换违规使用 std::async 得到解决。通过使用我自己的(依赖跟踪)线程池类，它在任务完成执行后尽快销毁任务，包括所有捕获的对象。 (它只是从队列中弹出任务信息对象，其中包含类型删除的任务、 promise 等。)

更新:应该注意 libstdc++ 的 std::packaged_task具有相同的行为，任务似乎已进入共享状态并且不会在 std::packaged_task 时被销毁。就是，只要get()或任何 future 的析构函数正在等待中。