使用std::async而不是手动创建std::thread对象的优点之一应该是std::async可以使用封面下的线程池来避免超额配置问题.但是哪些实现这样做？我的理解是微软的实现确实如此,但这些其他async实现呢？
boost::thread::async,不std::async)感谢您提供的任何信息.
我一直在考虑std::async以及如何在将来的编译器实现中使用它.但是,现在我有点陷入一种感觉像是设计缺陷的东西.
这std::async几乎与实现有关,可能有两种变体launch::async,一种是将任务启动到新线程,另一种是使用线程池/任务调度程序.
但是,根据用于实现的这些变体中的哪一个std::async,使用情况会有很大差异.
对于基于"线程池"的变体,您可以启动许多小任务而不必担心开销,但是,如果其中一个任务在某些时候阻塞了怎么办？
另一方面,"启动新线程"变体不会遇到阻塞任务的问题,另一方面,启动和执行任务的开销将非常高.
线程池: +低开销,永不阻塞
启动新线程: +精细的块,高开销
所以基本上取决于实现,我们使用的方式std::async会非常谨慎.如果我们有一个适用于一个编译器的程序,它可能在另一个编译器上工作可怕.
这是设计的吗？或者我错过了什么？你会像我一样考虑这个问题吗？
在当前的规范中,我遗漏了类似的东西std::oversubscribe(bool),以便实现依赖的使用std::async.
编辑:据我所知,C++ 11标准文档没有提供有关发送的任务是否std::async阻止的任何提示.
我正在观看由Bjarne Stroustrup撰写的GoingNative 2012第1天的演讲"C++ 11风格",自1:05:13起,他似乎在宣传而async()不是线程化.
我想知道,现在已经过去了4年,在C++世界中async(),在性能和控制方面,vs线程的优缺点是什么？
我迷失了不同的意见:
例如,关于性能:一个SO后C++ 11线程与异步性能(VS2013)说创建一个线程是昂贵的("Windows操作系统中的200 000个CPU周期"),但async()将使用更便宜的线程池; 但另一个SO帖子在C++ 11中async(launch :: async)会使线程池过时以避免昂贵的线程创建吗？不要这么认为("操作系统有很多理由他们应该尽可能地创建线程")
在控制方面,以前我的印象是线程允许更多的控制; 但一个SO发布async vs threading,何时使用每个选项？在C#上说"当你对低级线程参数进行控制时,线程有一些优点 - 这是非常罕见的."
另外,我认为性能/控制很大程度上取决于实现.所以我想知道,在Bjarne推广4年后async(),在性能和控制方面,与线程相比,它在C++世界中的表现如何？