std::atomic wait为何需要指定memory_order参数

开发者阿泽

2026-8-26

std::atomic::wait要传内存序参数根本不是多余设计，核心逻辑很简单：它本身就是个带阻塞能力的原子读操作，不是什么只负责等唤醒的空壳通知接收器，内存序就是用来定义这个读操作和其他线程写入之间的同步规则的。

首先得掰明白一个常见误区：从来没有“原子操作天然自带全同步效果”这回事，所有同步语义都是绑在你传的内存序参数上的。哪怕是最普通的load()，你传std::memory_order_relaxed的时候，它也不会和其他线程的release写入建立happens-before关系，wait()作为读类原子操作，当然遵循一模一样的规则。

你示例里给wait传relaxed，等返回了再单独做一次acquire序的load，写法完全没问题，但这只是用法之一，不是唯一的正确写法。wait的返回规则是“观察到原子值不等于你传进去的旧值”，当它被notify唤醒、满足返回条件的时候，它自己对原子值的读取完全可以承担同步职责：

要是你给wait传std::memory_order_acquire，那它返回的时候就已经和通知线程里对同一个原子变量做release写入的操作完成了同步，你根本不需要再额外调一次acquire的load，就能安全读到通知线程在写原子值之前改的所有内存数据。这种写法能少做一次冗余的原子读，在等待频率很高的场景下是实打实的性能收益。
给个最简的实现例子：

// 生产者线程
void push(Task t) {
    taskQueue.push(std::move(t)); // 普通非原子队列操作
    remainingTasks.fetch_add(1, std::memory_order_release); // release序写计数
    remainingTasks.notify_one();
}

// 消费者线程
Task pop() {
    ssize_t expected = 0;
    // wait本身用acquire序，返回时直接完成和生产者的同步
    while (remainingTasks.wait(expected, std::memory_order_acquire),
           remainingTasks.load(std::memory_order_relaxed) == 0) {
        expected = 0;
    }
    // 这里不需要额外加acquire操作，直接读队列不会有数据竞争
    Task t = taskQueue.pop();
    remainingTasks.fetch_sub(1, std::memory_order_relaxed);
    return t;
}

如果你需要多个不同原子变量的wait、读写操作保持全局顺序一致性，就给wait传std::memory_order_seq_cst，让它和其他seq_cst操作一起参与全局总序排序，满足特殊的并发正确性要求。
当然std::memory_order_relaxed也是合法参数，就像你写的示例那样，适合你打算在wait返回之后自己做额外原子读、自定义同步逻辑的场景。

最后提个容易忘的点：notify_one()/notify_all()本身不带任何内存序语义，两个线程靠wait/notify做同步的时候，同步关系完全是靠“wait侧的原子读”和“notify之前的原子写”这两个操作建立的。这就是wait必须暴露内存序参数的原因：它给了你选同步粒度的自由，你既可以让wait自己扛同步逻辑省掉冗余操作，也可以用relaxed配合后面的自定义原子操作，实现更灵活的同步流程。

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