C++20 barrier：别再手写“等所有人到齐再开饭”的线程同步了

你有没有写过这样的代码：启动一堆线程做并行计算，然后在最后卡一个 while (counter.load() != N) 或者用 condition_variable 配合 mutex 死等？——就像一群朋友约好晚上七点聚餐，每人出发时间不同，你站在餐厅门口反复看表、刷手机、问“到了吗？”，直到最后一个人喘着气推门进来，才松口气喊服务员上菜。这种“轮询+锁+条件等待”的组合，不仅难写易错，还藏着性能坑和唤醒丢失风险。

C++20 引入的 std::barrier，就是为了解决这个“等齐再行动”的经典场景而生的轻量级同步原语。它不共享状态、不依赖外部锁、不唤醒多余线程，一次初始化，多次复用，用完即走。

它不是 latch，也不是 mutex，更不是 condition_variable

先划清边界：

• std::latch 是一次性门闩（count-down only），到达零就永远卡住；
• std::mutex 解决的是临界区互斥，不是协作式等待；
• std::condition_variable 灵活但重，需要配套 mutex 和精心设计的谓词，稍不留神就死锁或虚假唤醒。

而 barrier 的核心契约只有一条：所有参与线程必须调用 arrive_and_wait()，且仅当第 N 个线程抵达时，全体才会同时被释放继续执行。 它内部无锁（通常基于原子操作+futex/futex-like 机制实现），无内存分配，也不要求调用线程具有唯一性——同一个线程可多次参与不同轮次的屏障同步。

一个真实可用的例子：并行矩阵乘法中的分块同步

假设你在写一个分块矩阵乘法（比如 C = A × B），把 A 按行分块、B 按列分块，每个线程负责计算一个子块 C[i][j] += A[i][k] × B[k][j]。但注意：C[i][j] 的最终结果依赖于所有 k 的累加，而 k 是循环变量——你不能让线程算完一个 k 就直接写 C[i][j]，否则会竞争。

传统做法？加 mutex 锁整个 C[i][j] ——性能崩盘；用 atomic_fetch_add？浮点加法不满足交换律，精度可能漂移；用 std::vector<std::atomic<double>>？内存开销大，且仍需处理归约顺序。

换种思路：把 k 当作屏障轮次。设 K 个分块，则声明：

std::barrier sync_barrier(K, [](const std::barrier& b) {
    // 所有线程完成本轮 k 后，自动触发此回调（可选）
    // 比如：检查是否需要提前终止、刷新缓存、记录日志
});

每个线程按 k = 0,1,...,K-1 顺序执行：

1. 计算本地临时块 tmp[i][j] += A[i][k] × B[k][j]（无共享写）；
2. 调用 sync_barrier.arrive_and_wait()；
3. 此时，所有线程都完成了第 k 轮计算，且 tmp 已就绪；
4. 全体线程一起将 tmp[i][j] 累加到 C[i][j] ——此时无竞争，因为每轮只有一组线程同时写同一 C[i][j]，且写前已同步完成。

关键点在于：barrier 把“分阶段协同”从逻辑层下沉到了同步原语层，你不再需要自己维护计数器、条件变量、唤醒逻辑。

注意两个易踩的“人情味”细节

第一，barrier 的 arrive_and_wait() 是阻塞调用，但它不保证唤醒顺序。别指望线程按 ID 或抵达顺序依次醒来——它只保证“全到齐，全放行”。如果你的算法隐含顺序依赖（比如某个线程必须最先处理结果），那 barrier 不适合，该换 std::counting_semaphore 或自定义调度。

第二，barrier 的析构是安全的，但前提是所有线程已离开 arrive_and_wait()。如果还有线程卡在等待中你就销毁了 barrier，行为未定义。实践中，要么确保生命周期覆盖全部同步轮次（比如作为类成员，在 join() 所有线程后再析构），要么用 std::shared_ptr<std::barrier> 配合 weak_ptr 做弱引用检测（小众但可靠）。

和 std::latch 搭配使用：一扇门 + 一道墙

有时你需要“先等全部线程启动完毕，再统一开始计时；结束后再等全部线程退出”。这时 latch 做“启动门”，barrier 做“执行墙”：

std::latch start_latch(N);
std::barrier work_barrier(N);

// 每个线程：
start_latch.arrive();     // 报到：我准备好了
start_latch.wait();      // 等所有人报到完毕
// → 此刻所有线程处于同一“起跑线”

for (int round = 0; round < 10; ++round) {
    do_work();
    work_barrier.arrive_and_wait(); // 每轮都等齐再进下一轮
}

这种组合干净利落，比嵌套 mutex+cv 清晰得多。

写在最后

std::barrier 不是银弹，它解决不了数据竞争、死锁或资源争用。但它精准切中了“N方协同等待”这一高频痛点，把原本需要十几行胶水代码才能稳住的逻辑，压缩成一行 arrive_and_wait()。

下次当你又想写 while (!done) { std::this_thread::yield(); }，或者翻出旧项目里那个叫 ThreadSyncHelper 的万能工具类时——停一下，查查 <barrier> 头文件。它不大，不重，不炫技，只是 quietly doing its job：让线程们，真正像一群人那样，一起出发，一起到达，一起行动。