C++线程屏障同步模式原子内存序误用问题排查

DevOps 小满

2026-8-27

问题根因

偶发断言失败不是单纯的内存序配置错误，是逻辑设计缺陷加内存序不匹配共同导致的，核心问题有三个：

锁变量与屏障标记复用引发跨轮次竞态
现有代码将barrier同时用作两个角色：控制面线程之间互斥的自旋锁标记、工作线程可见的屏障生效标记。当控制线程执行barrier_unlock()将barrier置为false时，其他等待自旋锁的控制线程会立刻抢锁成功，将barrier重新置为true，但此时前一轮屏障的workers_at_barrier计数还未清零——工作线程还没来得及执行--workers_at_barrier退出屏障，新旧两轮屏障的计数完全混杂。典型触发时序为：
- 控制线程C1完成共享资源修改，将barrier置为false，开始等workers_at_barrier降到0
- 等待锁的控制线程C2立刻通过exchange拿到锁，将barrier重新置为true，开始等workers_at_barrier升到2
- 工作线程W1先看到barrier为false，执行--workers_at_barrier把计数从2减到1，回到循环开头调用wait_at_barrier()，看到barrier已经被C2设为true，立刻执行++workers_at_barrier把计数加回2
- C2看到计数到2，从barrier_lock()返回，此时W2还没执行上一轮的--workers_at_barrier，等C2走到断言位置时，W2刚好执行--把计数改成1，直接触发断言
原子操作内存序配对错误
所有对workers_at_barrier的读-改-写操作没有显式指定适配场景的内存序，跨线程happens-before关系没有严格保证：
- 工作线程执行++workers_at_barrier标记到达屏障时，没有使用release语义，无法保证控制线程看到计数为2时，工作线程已经停止访问共享资源、真正停在屏障等待点
- 控制线程在循环中等待workers_at_barrier变化时，没有使用acquire语义，可能出现读到计数满足条件、但后续共享资源写操作被CPU重排到计数加载之前的问题
- 工作线程在屏障入口快速检查barrier为false直接返回时，虽然用了acquire加载，但没有和控制线程写入共享资源的release操作形成严格配对，极端场景下会读到旧的共享资源值
屏障入口存在竞态窗口
工作线程判断barrier == true和执行++workers_at_barrier两个操作之间没有做同步保护，极端情况下控制线程可能看到计数为2，但对应工作线程实际还未进入屏障等待逻辑，仍在访问共享资源。

修复方案

针对上述问题逐一修复：

拆分控制面自旋锁变量和屏障标记变量，保证只有等所有工作线程完全退出上一轮屏障、计数清零后，下一个控制线程才能拿到权限发起新一轮屏障同步，从根源上消除跨轮次计数混杂问题
为所有原子操作配置匹配的内存序，严格建立跨线程happens-before关系，保证共享资源的可见性：
- 工作线程更新到达/退出屏障的计数时使用memory_order_acq_rel，既保证之前的共享资源访问操作已完成，也保证计数更新对控制线程即时可见
- 控制线程等待计数变化时使用memory_order_acquire，禁止后续操作被重排到计数加载之前
- 控制线程置位/清零屏障标记时使用memory_order_release，工作线程加载屏障标记时使用memory_order_acquire，正确配对实现共享资源修改的跨线程可见性
所有自旋等待循环加入pause指令，降低自旋时的总线争抢和功耗开销，消除无意义的CPU占用。

修复后的完整代码如下：

#include <atomic>
#include <cstdint>
#include <cassert>

// 拆分控制面自旋锁与屏障标记，禁止变量复用
std::atomic_bool ctrl_lock{false};
std::atomic_bool barrier{false};
std::atomic_uint32_t workers_at_barrier{0};
constexpr uint32_t WORKER_THREAD_COUNT = 2;

// 控制面内部专用自旋锁，仅用于控制线程之间互斥，对工作线程不可见
void ctrl_lock_acquire()
{
    while (true)
    {
        if (!ctrl_lock.exchange(true, std::memory_order_acquire))
            break;
        while (ctrl_lock.load(std::memory_order_relaxed))
            __builtin_ia32_pause();
    }
}

void ctrl_lock_release()
{
    ctrl_lock.store(false, std::memory_order_release);
}

// 仅控制平面线程调用
void barrier_lock()
{
    // 先拿控制面互斥锁，保证同一时间只有一个控制线程操作屏障
    ctrl_lock_acquire();

    // 置位屏障标记，通知所有工作线程进入等待
    barrier.store(true, std::memory_order_release);

    // 等待所有工作线程到达屏障，acquire语义保证计数满时所有worker已停止访问共享资源
    while (workers_at_barrier.load(std::memory_order_acquire) != WORKER_THREAD_COUNT)
        __builtin_ia32_pause();
}

// 仅控制平面线程调用
void barrier_unlock()
{
    // 清零屏障标记，release语义保证之前对共享资源的修改对所有工作线程可见
    barrier.store(false, std::memory_order_release);

    // 等待所有工作线程完全退出屏障、计数清零
    while (workers_at_barrier.load(std::memory_order_acquire) != 0)
        __builtin_ia32_pause();

    // 所有worker退出后再释放控制面锁，禁止下一轮屏障提前启动
    ctrl_lock_release();
}

struct barrier_lock_guard
{
    barrier_lock_guard()
    {
        barrier_lock();
    }

    ~barrier_lock_guard()
    {
        barrier_unlock();
    }
};

// 控制平面线程请求处理入口
void handle_stuff()
{
    // ... 前置逻辑

    {
        barrier_lock_guard blg;
        // 此时屏障必然生效，所有worker已停在等待点，断言稳定通过
        assert(barrier.load(std::memory_order_relaxed) && 
               workers_at_barrier.load(std::memory_order_relaxed) == WORKER_THREAD_COUNT);

        // ... 写入/修改共享资源
    }

    // ... 后置逻辑
}

// 仅工作线程调用
void wait_at_barrier()
{
    // 快速路径：屏障未生效时直接返回，acquire语义保证能看到控制线程之前对共享资源的所有修改
    if (!barrier.load(std::memory_order_acquire))
        return;
    
    // 标记到达屏障：acq_rel语义保证之前的共享资源读操作已完成，计数更新对控制线程可见
    workers_at_barrier.fetch_add(1, std::memory_order_acq_rel);

    // 阻塞等待屏障释放，acquire语义配对控制线程unlock时的release
    while (barrier.load(std::memory_order_acquire))
        __builtin_ia32_pause();

    // 标记退出屏障：acq_rel语义保证计数更新对控制线程可见
    workers_at_barrier.fetch_sub(1, std::memory_order_acq_rel);
}

// 工作线程主逻辑
void workers_stuff()
{
    while (true)
    {
        wait_at_barrier();
        // ... 只读访问共享资源，处理报文
    }
}

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