C++20 std::atomic<bool>::wait是否淘汰C++17条件变量同步方案？

C++20 std::atomic::wait 新方案 #

data d;
std::atomic<bool> ready = false;

void consume_bool() {
    ready.wait(false);
    do_consume(d);
    ready.store(false);
    ready.notify_one();
}

void produce_bool() {
    ready.wait(true);
    d = do_produce();
    ready.store(true);
    ready.notify_one();
}

C++17 std::mutex + std::condition_variable 传统方案 #

data d;
std::mutex m;
std::condition_variable consume_ready, produce_ready;
bool ready = false;

void consume_cv() {
    std::unique_lock lock{m};
    consume_ready.wait(m, [] { return ready; });
    do_consume(d);
    ready = false;
    produce_ready.notify_one();
}

void produce_cv() {
    std::unique_lock lock{m};
    produce_ready.wait(m, [] { return !ready; });
    d = do_produce();
    ready = true;
    consume_ready.notify_one();
}

为什么仍会使用std::mutex和std::condition_variable？ #

• 兼容性限制：不少项目还在基于C17或更早版本开发，没法直接用C20的atomic wait特性，尤其是要兼容旧编译器、老操作系统的场景，只能继续用传统方案。
• 复杂场景的灵活性：如果同步逻辑涉及多个条件组合、批量通知等复杂需求，mutex配合condition_variable的组合能更灵活地处理；而atomic wait只能针对单个原子变量的特定值等待，应对复杂场景时局限性明显。
• 存量代码维护成本：大量现有系统已经用mutex+cv实现了同步，重构为atomic方案需要额外的测试、验证成本，对于稳定运行的系统来说，没必要冒风险改动。
• 语义直观性：mutex明确标记了临界区范围，condition_variable的等待/通知逻辑在团队协作中更容易被理解和维护；而atomic wait在多变量同步场景下，代码逻辑可能会变得晦涩难懂。

std::atomic::wait 是否和std::condition_variable一样高效（无忙等）？ #

是的，std::atomic<T>::wait 设计时就保证了无忙等——底层实现和condition_variable类似，会让线程进入休眠状态，直到被notify唤醒，不会占用CPU做循环检查。

在单生产者-单消费者的简单场景下，两者性能差异极小。atomic wait的优势在于不需要额外的mutex，减少了锁的加解锁开销，在极致性能要求的场景下可能略占上风。但在复杂同步场景中，mutex+condition_variable的组合依然是更通用的选择。

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