c++ - 为什么从 `std::async` 阻塞返回的 future 的析构函数？

Question

当试图回答另一个 Stackoverflow question ，我意识到这个简单的 C++11 片段隐式阻塞了调用线程:

std::async(std::launch::async, run_async_task)

对我来说，这似乎是规范的 C++11 异步启动任务而不关心结果的方式。相反，为了实现这一点，显然必须显式地创建和分离一个线程(参见 answer 到提到的问题)。

所以这是我的问题:std::future 的析构函数必须阻塞的安全性/正确性是否有任何原因？如果它只阻塞在 get 上还不够吗，否则，如果我对返回值或异常不感兴趣，那它只是一劳永逸？

Answer 1

阻塞 std::async 返回的 future 和线程的析构函数:这是一个有争议的话题。以下按时间顺序排列的论文列表反射(reflect)了委员会成员的一些讨论:

• N2802: A plea to reconsider detach-on-destruction for thread objects汉斯·伯姆(Hans Boehm)
• N3630: async, ~future, and ~thread (Revision 1)作者:赫伯萨特
• N3636: ~thread Should Join作者:赫伯萨特
• N3637: async and ~future (Revision 3)作者:Herb Sutter、Chandler Carruth、Niklas Gustafsson
• N3679: Async() future destructors must wait汉斯·伯姆(Hans Boehm)
• N3773: async and ~future (Revision 4)作者:Herb Sutter、Chandler Carruth、Niklas Gustafsson
• N3776: Wording for ~future作者:赫伯萨特
• N3777: Wording for deprecating async作者:赫伯萨特

尽管进行了很多讨论，但 C++14 没有计划对 std::future 和 std::thread 。

关于您的问题，最有趣的论文可能是 Hans Boehm 的第二篇论文。我引用一些部分来回答你的问题。

N3679: Async() future destructors must wait

[..] Futures returned by async() with async launch policy wait in their destructor for the associated shared state to become ready. This prevents a situation in which the associated thread continues to run, and there is no longer a means to wait for it to complete because the associated future has been destroyed. Without heroic efforts to otherwise wait for completion, such a "run-away" thread can continue to run past the lifetime of the objects on which it depends.

[Example]

The end result is likely to be a cross-thread "memory smash". This problem is of course avoided if get() or wait() is called [..] before they [the futures] are destroyed. The difficulty [..] is that an unexpected exception may cause that code to be bypassed. Thus some sort of scope guard is usually needed to ensure safety. If the programmer forgets to add the scope guard, it appears likely that an attacker could generate e.g. a bad_alloc exception at an opportune point to take advantage of the oversight, and cause a stack to be overwritten. It may be possible to also control the data used to overwrite the stack, and thus gain control over the process. This is a sufficiently subtle error that, in our experience, it is likely to be overlooked in real code.

更新:Michael Wong 的旅行报告还包含一些关于 2013 年 9 月 session 成果的有趣信息:

The View from the C++ Standard meeting September 2013 Part 2 of 2.

On the issue that async destructors should not block we devoted a great deal of discussion on it. [..] The only position that received considerable support was [..] giving advisory that future destructors will not block, unless returned from async, making it the notable exception. [..] After significant discussion, the only part that we tried to carry was N3776, an attempt to clarify the position that ~future and ~shared_future don’t block except possibly in the presence of async. There was an attempt to issue a deprecation along the lines of C. Deprecate async without replacement. This motion was actually almost put forward. But [..] it died even before it reached the operating table.