问题标签 [packaged-task]

（在 Ubuntu 18.04 上使用 C++17 和 g++ 7.5.0）
下面的 dp1 工作正常，但 dp2 导致以下错误：

未定义对“pthread_create”
collect2 的引用：错误：ld 返回 1 个退出状态

试图与packaged_task<T>

std::asyncstd::future<T>使用类模板和方法创建一个异步执行的线程并处理我们可以访问的数据get()。

我应该知道什么是如何packaged_task<T>工作的，有什么不同std::async？

packaged_task<T>当我们调用该task(x)函数时，是否创建了与该线程相关的线程？

以代码示例：

我知道了future返回 from的原因std::async有一些特殊的共享状态，通过这种共享状态wait on returned future发生在未来的析构函数中。但是当我们使用 时std::pakaged_task，它的未来不会表现出相同的行为。要完成打包任务，您必须显式调用get()来自 的future对象packaged_task。

现在我的问题是：

1. std::async未来（thinking vs ）的内部实现可能是什么std::packaged_task？
2. 为什么相同的行为不适用于future返回 from std::packaged_task？或者，换句话说，如何停止相同的行为std::packaged_task future？

要查看上下文，请参阅以下代码：

它不等待完成countdown任务。但是，如果我取消评论// int value = ret.get();，它将完成countdown并且很明显，因为我们实际上是在阻止返回的未来。

如果我使用在另一个线程上std::async执行任务countdown，无论我是否在get()返回的future对象上使用，它都会完成任务。

以下程序似乎是与显式构造函数相关的错误。但是，我无法找到答案。

使用 Visual Stduio 2017，构建时出现以下错误：

我从https://pastebin.com/MM5kSvH6复制了以下线程池实现。一切看起来都不错，但我无法理解第 32 行和第 71 行的逻辑。这两行不是都在尝试执行该功能吗？我想在线程池中，线程应该从任务队列中提取任务然后执行它？从这个意义上说，第 71 行看起来不错，但我对第 32 行感到困惑。为什么不将任务添加到队列中，为什么要尝试执行相同的操作？

我有一个相当复杂的代码，其中包含std::async调用和std::packaged_task，但无法执行到最后。我将其简化为最小的可重现示例。

两个 async 函数一个接一个地被调用，其中有 packaged_tasks 使用std::async. future.wait()然后我们都使用相应的方法等待两个异步函数完成。执行停止在futY.wait();并且第二个packaged_task永远不会执行（没有第二个Inside handler func日志）。

日志如下：

您能否解释一下为什么代码直到最后才执行？

为什么转换构造函数是std::packaged_task explicit，而同一个构造函数std::function不是？我找不到任何理由。

例如，这在将 lambda 作为参数传递给以 a packaged_task（或对它的引用）作为参数的函数时强制转换：

下面是我的调度程序的简化版本。单个线程按入队顺序处理 packaged_tasks。

• execute安排并等待任务完成
• schedules将任务排入队列并立即返回给用户
• drain简单地将一个空任务排入队列，其想法是一旦我们到达它，我们就知道所有先前调度的命令都已执行

问题：这里有什么保证drain不会被优化吗？我已经用几个编译器测试了这个示例程序，-O3但没有一个优化空 lambda 调用。是否有足够的可观察行为（mTasks列表的操作、同步屏障等）使该排水实现有效？标准是怎么说的？

我不确定为什么下面的代码在此处的在线编译器中运行时会引发运行时异常。我正在尝试通过打包任务执行功能

我得到的错误是