C++实现异步任务的任务链式异步执行 _ future与promise实战【源码】-C++-PHP中文网

std::promise和std::future不能链式调用是因为get()阻塞且标准库无.then()回调机制；需通过轮询wait_for+线程池模拟链式，或用shared_ptr管理promise生命周期避免析构崩溃。

c++实现异步任务的任务链式异步执行 _ future与promise实战【源码】

std::promise 和 std::future 为什么不能直接链式调用

因为 std::future 的 get() 是阻塞的，而链式执行要求“前一个任务完成自动触发下一个”，不能靠手动 get() 等待——那和同步没区别。标准库里没有 .then()，C++11/14 的 std::future 也不支持就绪通知回调。

常见错误是这样写：

auto f1 = std::async([]{ return 42; });
auto f2 = std::async([f1]{ return f1.get() * 2; }); // 错！f1.get() 在构造 f2 时就阻塞了

真正可行的路径只有两条：自己实现通知机制（基于条件变量 + 状态轮询），或借助第三方（如 libunifex、cppcoro），或升级到 C++20 协程 + std::jthread 配合手动调度——但本例聚焦“纯标准库 + promise/future 实战”，所以采用轻量级轮询+线程解耦方案。

用 std::promise 手动控制 future 就绪时机

std::promise 的核心价值不是“发数据”，而是“发状态”。它让异步任务能决定何时把 std::future 标记为 ready，从而解耦生产者与消费者线程。

一个 std::promise 只能调用一次 set_value() / set_exception()，多次调用会抛 std::future_error（错误码 std::future_errc::promise_already_satisfied）
不要在 promise 析构前忘记设置值，否则等待它的 future 会永远阻塞（或抛 std::future_error，取决于是否已调用 get()）
若需多消费者共享结果，用 std::shared_future 替代 std::future

典型结构：

std::promise<int> p;
auto f = p.get_future();
<p>std::thread([&p]{
std::this_thread::sleep_for(100ms);
p.set_value(123); // 此刻 f.ready() 变 true
}).detach();</p></int>

模拟链式：用 future.wait_for(0) 轮询 + 线程池触发下一级

没有回调？那就主动问。用极短超时轮询 future.wait_for(std::chrono::nanoseconds(1)) 判断就绪，一旦返回 std::future_status::ready，立刻提交下个任务到线程池——这是最轻量、零依赖的链式模拟方式。

注意点：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

轮询频率不能太高（避免 CPU 空转），wait_for(0) 是最低开销，但某些平台仍可能被调度器惩罚；推荐 wait_for(1us) 或配合 yield
必须捕获 std::future_status::deferred（表示任务尚未启动），否则轮询会立即返回 false，误判失败
下一级任务的输入参数应来自上一级 get()，但只能在确认 ready 后调用，否则会阻塞

示例节选（无锁简化版）：

template<typename t typename f>
void then(std::future<t>&& prev, F&& func) {
    auto pool = get_thread_pool();
    pool->push([fut = std::move(prev), func = std::forward<f>(func)]() mutable {
        while (fut.wait_for(1us) != std::future_status::ready) {}
        try {
            auto res = fut.get(); // 此时必不阻塞
            pool->push([res, func = std::move(func)] { func(res); });
        } catch (...) { /* 处理异常 */ }
    });
}</f></t></typename>

实际链式任务中 promise 生命周期容易出问题的地方

最常崩的位置：promise 对象在线程外提前析构，但线程内还试图调用 set_value() —— 这是未定义行为，大概率 crash。

安全做法只有两种：

把 std::promise 捆进 std::shared_ptr，传给 worker 线程，确保 set 前 promise 一定活着
用局部 std::promise + std::packaged_task 包装函数，由 packaged_task 自动管理 promise 生命周期

反例（危险）：

std::future<int> bad_chain() {
    std::promise<int> p;
    auto f = p.get_future();
    std::thread([p = std::move(p)]{ // ❌ p 是副本，析构后 set_value 无效
        p.set_value(42);
    }).detach();
    return f;
}</int></int>

正例（推荐）：

std::future<int> good_chain() {
    auto p = std::make_shared<:promise>>();
    auto f = p->get_future();
    std::thread([p]{ 
        std::this_thread::sleep_for(10ms);
        p->set_value(42); // ✅ p 共享指针保活
    }).detach();
    return f;
}</:promise></int>

复杂点不在语法，而在 promise 和 future 的所有权转移时机、线程间生命期对齐——漏掉任意一环，链就断在 silent crash 里。