shared_future<void>能否替代condition_variable？是否存在必须使用后者的场景？

Great question! Let's break down when std::condition_variable is irreplaceable even when you have shared_future<void> at your disposal, based on their core differences and real-world synchronization needs.

1. Repeated synchronization events #

shared_future<void> is a one-shot mechanism: once it enters the ready state, it stays that way forever. If you need to trigger synchronization multiple times (like a producer-consumer queue where new items arrive periodically), shared_future can't help—you'd have to create a new future every time, which is clunky, inefficient, and hard to maintain.

In contrast, std::condition_variable is built for repeated signaling. You can call notify_one() or notify_all() as many times as needed, and threads can wait on the same condition variable repeatedly after each signal. Take this classic producer-consumer example:

#include <queue>
#include <mutex>
#include <condition_variable>

std::queue<int> task_queue;
std::mutex queue_mutex;
std::condition_variable queue_cv;

// Producer thread: adds tasks to the queue
void produce_task(int task_id) {
    std::lock_guard<std::mutex> lock(queue_mutex);
    task_queue.push(task_id);
    queue_cv.notify_one(); // Wake just one waiting consumer
}

// Consumer thread: waits for and processes tasks
void consume_tasks() {
    while (true) {
        std::unique_lock<std::mutex> lock(queue_mutex);
        // Wait until the queue isn't empty (filters spurious wakeups too)
        queue_cv.wait(lock, []{ return !task_queue.empty(); });
        
        int task = task_queue.front();
        task_queue.pop();
        lock.unlock();
        
        // Process the task...
    }
}

This pattern relies on the condition variable's reusability—something shared_future<void> can't replicate without significant overhead.

2. Conditional waiting with dynamic predicates #

shared_future<void> only lets you wait for a single, static condition: "has this future been made ready?". But many synchronization scenarios require waiting for a dynamic, state-dependent condition—like waiting for a queue to not be empty, a counter to reach a threshold, or a flag to be set and a resource to be available.

std::condition_variable pairs perfectly with a mutex and a predicate (the second argument to wait()) to handle these cases. The predicate checks if your actual desired condition is met, which also eliminates spurious wakeups. shared_future has no way to tie into such dynamic application state; its ready status is entirely independent of your program's runtime logic.

3. Selective thread wakeups #

When you make a shared_future<void> ready, all threads waiting on it will wake up immediately. There's no way to wake just one specific thread (like you can with cv.notify_one()). This is a problem if you only need one thread to handle an event—waking all waiting threads wastes CPU cycles and can lead to unnecessary contention as multiple threads race to process the same task.

For example, in a thread pool with idle workers, you'd want to wake just one worker when a new task arrives. shared_future can't do this; it would wake every worker, which is inefficient and could cause bottlenecks.

4. Late-arriving waiters #

If a thread starts waiting on a shared_future<void> after it's already been made ready, the thread will immediately proceed without waiting. But in some scenarios, you need late-arriving threads to wait for the next occurrence of an event, not just check if a past event happened.

std::condition_variable handles this seamlessly: a thread that starts waiting later will simply block until the next notify call, which aligns with use cases where events happen repeatedly over time.

Wrap-up #

As Josuttis noted, it's best to prefer high-level constructs like future where possible—they're safer and more expressive for one-shot results or simple synchronization. But when you need repeated signaling, dynamic conditional waits, selective wakeups, or support for late-arriving waiters, std::condition_variable becomes indispensable. There's no clean way to replicate these behaviors with shared_future<void>.

内容的提问来源于stack exchange，提问作者SSteven