c++ - std::promise 的任何情况都不能被运行顺序生产然后消费的单个线程替换吗？

Question

2020 年 6 月 9 日更新:整合此处的所有评论和答案，并对此进行更多思考，我在下面创建了一个流程图(单击放大)来帮助决定何时使用 std::promise/future，以及需要权衡什么。

原帖如下:

我一直在思考 std::promise/future 机制的真正好处。几乎到处都在宣传这种模式的示例 - 单个生产者、单个生产者场景，其中生产者一次性通知消费者相关资源已准备好消费:

#include <iostream>
#include <future>
#include <thread>
using namespace std::chrono_literals;

struct StewableFood {
    int tenderness;
};

void slow_cook_for_12_hours(std::promise<StewableFood>& promise_of_stew) {
    std::cout << "\nChef: Starting to cook ...";

    // Cook till 100% tender
    StewableFood food{ 0 };
    for (int i = 0; i < 10; ++i) {
        std::this_thread::sleep_for(10ms);
        food.tenderness = (i + 1) * 10;
        std::cout << "\nChef: Stewing ... " << food.tenderness << "%";
    }

    // Notify person waiting on the promise of stew that the promise has been fulfilled.
    promise_of_stew.set_value(food);
    std::cout << "\nChef: Stew is ready!";
}

void wait_to_eat_stew(std::future<StewableFood>& potenial_fulfilment_of_stew) {
    std::cout << "\nJoe: Waiting for stew ...";
    auto food = potenial_fulfilment_of_stew.get();
    std::cout << "\nJoe: I have been notified that stew is ready. Tenderness " << food.tenderness << "%! Eat!";
}

int main()
{
    std::promise<StewableFood> promise_of_stew;
    auto potenial_fulfilment_of_stew = promise_of_stew.get_future();

    std::thread async_cook(slow_cook_for_12_hours, std::ref(promise_of_stew));
    std::thread async_eat(wait_to_eat_stew, std::ref(potenial_fulfilment_of_stew));

    async_cook.join();
    async_eat.join();

    return 0;
}

对我来说，所有这些异步性都没有任何意义，因为最终，消费者在 future::get 上的阻塞等待使得这种用法相当于具有顺序生产然后的单线程用法。消耗。我最初认为我上面的例子是人为的。但是，如果我们查看 std::promise/future 对的一次性使用约束(即，您不能重写原始 Promise，也不能重新读取来自最初的 future )，因此上面的示例成为唯一可行的用例，因为:

1. 一次性约束意味着只能有一个生产者，并且
2. 获取一次约束意味着只能有一个消费者，并且
3. 从上述 2 个 set/get-once 约束推断，不应存在导致同一 Promise/Future 重复使用的循环。

如果上面示例中的使用模式确实是唯一可行的用例，那么与仅执行以下操作相比，使用 std::promise 没有任何优势:

void cook_stew_then_eat() {
    auto stew = slow_cook_for_12_hours();
    // wait 12 hours
    eat_stew(stew);
}

int main() {
    std::thread t(cook_stew_then_eat);
    t.join();

    return 0;
}

现在看来，这个结论似乎很可疑。我非常确定 std::promise 有一个很好的用例，它不能被单线程顺序生产然后消费版本替换，该版本不涉及std::promise。

问题:该用例是什么？

注意:很容易推测，也许std::promise/future 以某种方式允许我们异步执行其他操作而无需等待满足感——这可能是优势吗？绝对不是，因为我们可以通过将“其他东西”(例如一些重要的工作)放在另一个线程中来实现相同的效果。举例说明:

// cook and eat threads use std::promise/future
std::thread cook(...);
std::thread eat(...);

// Let's do important work on another thread
std::thread important_work(...);

cook.join();
eat.join();
important_work.join();

与不使用 std::promise/future 的解决方案相同:

// sequentially cook then eat, NO NEED to use std::promise/future
std::thread cook_then_eat(...);

// Let's do important work on another thread
std::thread important_work(...);

cook_then_eat.join();
important_work.join();

Answer 1

不，你实际上是正确的，如果你小心同步和对象生命周期， future / promise 模式总是可以被手动线程管理(通过线程连接、条件变量和互斥体)取代。

future / promise 模式的主要好处是抽象。它向您隐藏了共享状态的生命周期管理和同步，使您摆脱了自己执行此操作的负担。

一旦生产者有了 promise ，它就不需要了解有关消费方的任何其他信息，对于消费者和 future 也是如此。这使得编写更简洁、更不易出错且耦合更少的代码成为可能。

另请记住，从 C++20 开始，std::future 仍然缺少 continuations ，这使得它的功能远不如应有的强大。