问题标签 [stdasync]

我正在尝试使用创建线程std::async，但我不断收到错误“没有匹配函数调用'<code>async(std::launch,<unresolved 重载函数类型>,std::string&)'”在线

这是产生这种行为的代码：

我正在启动几个异步任务，如下所示：

我有一个功能需要知道所有这些任务是否已完成：

我知道我可以像这样等待异步任务：

我从这个链接中看到Waiting for multiple futures? 还没有等待多个期货。

有什么技巧可以用来查看我的所有任务是否已完成？

我可以将每个未来存储在一个数组或向量中并依次等待每个未来吗？

我编写了以下代码来测试在 Ubuntu 上使用 GCC 4.8.2std::async()返回的函数。void

如果i.get();未注释，则消息"Print here"始终存在；然而，如果i.get();被注释掉，"Print here"当且仅当USE_ASYNC被定义时才存在（也就是说，std::launch::async总是导致消息打印出来，而std::launch::deferred从不）。

这是有保证的行为吗？确保异步调用返回void执行的正确方法是什么？

我有一段代码使用std::async. 这是我通过调用的函数async：

可以看到，它的返回值为cv::Mat.

现在在我的代码中的某处，我声明了一个用于返回async调用的变量，如下所示：

在其他一些时候，实际的调用看起来像这样：

现在，在这一行中，IntelliSense 将等号下划线并显示以下错误消息：

但是，代码编译并运行良好。现在，这只是一个 IntelliSense 问题还是我应该以不同的方式声明我的返回值？IDE 是 Visual Studio 2013。

I'm attempting to implement std::async from scratch, and have run into a hiccup with arguments of move-only type. The gist of it is, C++14 init-captures allow us to capture single variables "by move" or "by perfect forwarding", but they do not appear to let us capture parameter packs "by move" nor "by perfect forwarding", because you can't capture a parameter pack by init-capture — only by named capture.

I've found what appears to be a workaround, by using std::bind to capture the parameter pack "by move", and then using a wrapper to move the parameters out of the bind object's storage into the parameter slots of the function I really want to call. It even looks elegant, if you don't think too much about it. But I can't help thinking that there must be a better way — ideally one that doesn't rely on std::bind at all.

(Worst case, I'd like to know how much of std::bind I'd have to reimplement on my own in order to get away from it. Part of the point of this exercise is to show how things are implemented all the way down to the bottom, so having a dependency as complicated as std::bind really sucks.)

My questions are:

• How do I make my code work, without using std::bind? (I.e., using only core language features. Generic lambdas are fair game.)

• Is my std::bind workaround bulletproof? That is, can anybody show an example where the STL's std::async works and my Async fails?

• Pointers to discussion and/or proposals to support parameter-pack capture in C++1z will be gratefully accepted.

Here's my code:

我有点困惑从 c++ 中的异步函数返回大数据的正确方法是什么。

以这段代码为例。它在函数中创建一个大向量并返回分配的向量。

对我来说，这打印

所以显然，在主线程中调用函数时，返回值省略或移动就完成了。但是未来的返回值显然被复制了。此外，在尝试使用std::move标记的行时MOVE[1,2]，调用的返回时间future.get()保持不变。另一方面，当返回一个指针时，返回时间future.get()可以忽略不计（我是 0ms）。

那么大数据必须通过指针从期货返回吗？

我正在尝试将多个std::futures 保存在一个QMap. 这QMap是我班级的成员变量：

我现在想std::async在这张地图中存储多次调用的结果，如下所示：

此处异步调用的函数readImage如下所示：

所以异步函数的返回值应该是std::future<cv::Mat>我认为的。但是，在尝试编译时，Visual Studio 2015 给了我以下编译器错误：

令我困惑的是返回类型std::future<cv::Mat (&)(QString path, bool emitSignals)>，这与std::future<cv::Mat>我的预期不同。

我想用std::async为静态类测试以下函数，我的主要目的是等到函数执行。但我面临以下错误。有人可以给我这个错误的原因。

调试上述行后，我收到以下错误。

错误 LNK2019：未解析的外部符号 __imp___CrtDbgReportW 在函数“受保护：__thiscall Concurrency::details::_RefCounter::_RefCounter(long)”中引用 (??0_RefCounter@details@Concurrency@@IAE@J@Z)

有人可以回答我为什么我会遇到错误。

太感谢了。

我认为使用多线程处理简单而繁重的工作（例如矩阵计算）比使用单线程更好，因此我测试了以下代码：

执行环境：

在调试模式下构建这个程序时，结果如我所料：

这表示不使用 std::async 的代码与使用单线程的代码具有相同的性能，并且当使用 4 或 8 个线程时，我可以获得出色的性能。

但是，在发布模式下，我得到了不同的结果 (N : 100000 -> 100000000)：

我想知道这个结果。只是对于后半部分代码，多线程的性能比单线程更好。但最快的是前半部分代码，它不使用 std::async。我知道多线程的优化和开销对性能有很大影响。然而，

• 该过程只是向量的计算，那么在多线程代码中而不是在单线程代码中可以优化什么？
• 该程序不包含任何关于互斥或原子等的内容，并且可能不会发生数据冲突。我认为多线程的开销会相对较小。
• 不使用 std::async 的代码中的 CPU 利用率小于多线程代码中的 CPU 利用率。使用大部分 CPU 是否有效？

更新：我试图研究矢量化。我启用/Qvec-report:1了选项并得到了事实：

和运行时间：

可以肯定的是，for-loop 在多线程版本中没有向量化。但是，由于任何其他原因，该版本也需要很多时间。

更新 2：我在 lambda 中重写了 for 循环（A 型到 B 型）：

B型运行良好。结果 ：

类型 B 的结果是可以理解的（多线程代码会比单线程向量化代码运行得更快，并且不如向量化代码快）。另一方面，A 型似乎等同于 B 型（仅使用临时变量），但它们显示出不同的性能。这两种类型可以认为是产生了不同的汇编代码。

更新 3：我可能会发现一个减慢多线程 for 循环的因素。是条件下的除法for。这是单线程测试：

和运行时间：

版本 3 和 4得到了很好的优化，版本 1没有那么多，因为我认为编译器无法捕捉到 N 是不变的，尽管 N 是constexpr. 由于同样的原因，我认为第 2 版非常慢。编译器不明白 N 和 Q 不会变化。所以这个条件i < N / Q需要大量的汇编代码，这会减慢 for 循环。

我在 std::thread 和 std::async 之间做了一个测试代码。

使用 4 核 CentOS 7 机器（gcc 4.8.5），版本 1（使用 std::thread）与其他实现相比大约慢 100 倍。

为什么线程版本这么慢？我认为每个线程不会花费很长时间来完成Log::WriteLog功能。