Effective Modern C++ 条款36 如果异步执行是必需的,指定std::launch::async策略
来源:互联网 发布:网络女主播现实不好看 编辑:程序博客网 时间:2024/06/04 18:02
如果异步执行是必需的,指定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); // 使用默认发射策略执行fauto 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的持续时间后缀,请看条款34void f() // f睡眠1秒后返回{ std::this_thread::sleep_for(1s);}auto fut = std::async(f); // (概念上)异步执行fwhile(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>inlinestd::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>inlineautoreallyAsync(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发射策略。
- Effective Modern C++ 条款36 如果异步执行是必需的,指定std::launch::async策略
- Effective modern C++ 条款 38:如果异步至关重要请指定std::launch::async
- Effective Modern C++ 条款18 用std::unique_ptr管理独占所有权的资源
- Effective Modern C++ 条款19 用std::shared_ptr管理共享所有权的资源
- Effective Modern C++ 条款33 对需要std::forward的auto&&参数使用decltype
- Effective Modern C++ 条款20 把std::weak_ptr当作类似std::shared_ptr的、可空悬的指针使用
- Effective Modern C++ 条款23 理解std::move和std::forward
- 《Effective Modern C++》翻译--条款4:了解如何查看推导出的类型
- 《Effective Modern C++》翻译--条款1: 理解模板类型推导
- 《Effective Modern C++》翻译--条款3: 理解decltype
- Effective Modern c++ 条款总结
- Effective Modern C++ 条款34 比起std::bind更偏向使用lambda
- Effective Modern C++ 条款29 假设移动操作是不存在的、不廉价的、不能用的
- Effective Modern C++ 条款21 比起直接使用new,更偏爱使用std::make_unique和std::make_shared
- Effective Modern C++ 条款25 对右值引用使用std::move,对通用引用使用std::forward
- 《Effective C++》:条款36-条款37
- 《Effective Modern C++》读书笔记
- Effective Modern C++(笔记)
- SSH搭建时的错误之(1) Error creating bean with name 'testService' defined in class path resource
- JQuery鼠标滚轮事件
- centos6.5安装maridb5.5.51
- 地图与定位
- 欢迎使用CSDN-markdown编辑器
- Effective Modern C++ 条款36 如果异步执行是必需的,指定std::launch::async策略
- Mybatis中SqlSession下的四大核心组件分析
- Lightoj1082——Array Queries(线段树+求区间最小值)
- 10个最好的 Node.js MVC 框架
- 蓝牙 status 133
- windows 创建 别名 快速 调用命令
- hdu-5873-Football Games
- 算法设计中的会场安排问题
- Python格式化输出