跨对象/线程的共享屏障实现方案问询：动态计数场景下的std::barrier使用问题及替代方案探讨

这个问题属于典型的动态计数线程同步场景，咱们一步步拆解可行的解决方案，再聊聊你提到的忙等信号量是否合适：

核心问题拆解 #

你遇到的std::barrier痛点非常明确：它要求构造时固定计数，但ObjB的数量要等ObjA构造完成后才能确定；如果延迟在业务函数里创建，ObjB又无法安全访问。针对这个问题，我们可以用标准库组件适配，或者自定义同步逻辑，具体分两种场景：

场景1：一次性同步（仅需等待所有ObjB到达一次） #

如果你的需求是只需要让ObjA等待一次所有ObjB触发条件（比如所有ObjB完成初始化后，ObjA再继续执行），std::latch（C++20引入）是最佳选择——它是一次性的计数同步器，计数减到0后触发等待线程。我们可以用智能指针延迟初始化它：

#include <memory>
#include <vector>
#include <latch>
#include <stdexcept>

class ObjA : public std::enable_shared_from_this<ObjA> {
private:
    std::vector<std::unique_ptr<ObjB>> objBs;
    std::shared_ptr<std::latch> completionLatch;

public:
    // 创建指定数量的ObjB，并初始化同步器
    void setupObjBs(size_t objCount) {
        objBs.reserve(objCount);
        for (size_t i = 0; i < objCount; ++i) {
            // 用weak_ptr避免循环引用
            objBs.emplace_back(std::make_unique<ObjB>(weak_from_this()));
        }
        // 此时确定计数，初始化latch
        completionLatch = std::make_shared<std::latch>(objCount);
    }

    // ObjB调用此函数标记自己已到达条件
    void markAsReady() {
        if (!completionLatch) {
            throw std::runtime_error("Latch not initialized");
        }
        completionLatch->count_down();
    }

    // ObjA等待所有ObjB就绪
    void waitForAllReady() {
        if (completionLatch) {
            completionLatch->wait();
        }
    }
};

class ObjB {
private:
    std::weak_ptr<ObjA> parent;

    // 模拟内部条件判断
    bool checkInternalCondition() {
        // 实际业务逻辑：比如任务完成、状态达标等
        return true;
    }

public:
    explicit ObjB(std::weak_ptr<ObjA> p) : parent(std::move(p)) {}

    void work() {
        // 执行任务直到满足内部条件
        while (!checkInternalCondition()) {
            // do work...
        }
        // 通知ObjA自己已就绪
        if (auto a = parent.lock()) {
            a->markAsReady();
        }
    }
};

这个方案完全依赖标准库，线程安全且无需自己实现同步逻辑，是一次性同步场景的首选。

场景2：可重复同步（需要多次等待ObjB触发条件） #

如果你的需求是ObjB会循环执行任务，每次都要在某个节点和ObjA同步，可以结合std::barrier和条件变量实现：std::barrier负责让所有ObjB同步到达节点，然后通过它的完成函数通知ObjA解锁：

#include <memory>
#include <vector>
#include <barrier>
#include <mutex>
#include <condition_variable>
#include <stdexcept>

class ObjA : public std::enable_shared_from_this<ObjA> {
private:
    std::vector<std::unique_ptr<ObjB>> objBs;
    std::shared_ptr<std::barrier<>> syncBarrier;
    std::mutex cvMutex;
    std::condition_variable syncCV;
    bool barrierTriggered = false;

    // 屏障完成时的回调：通知ObjA解锁
    void onBarrierComplete() {
        std::lock_guard<std::mutex> lock(cvMutex);
        barrierTriggered = true;
        syncCV.notify_one();
    }

public:
    void setupObjBs(size_t objCount) {
        objBs.reserve(objCount);
        for (size_t i = 0; i < objCount; ++i) {
            objBs.emplace_back(std::make_unique<ObjB>(weak_from_this()));
        }
        // 初始化barrier，绑定完成回调
        syncBarrier = std::make_shared<std::barrier<>>(
            objCount,
            [this]() { onBarrierComplete(); }
        );
    }

    // ObjB调用此函数到达屏障
    void arriveAtBarrier() {
        if (!syncBarrier) {
            throw std::runtime_error("Barrier not initialized");
        }
        syncBarrier->arrive_and_wait();
    }

    // ObjA等待所有ObjB到达屏障
    void waitForBarrier() {
        std::unique_lock<std::mutex> lock(cvMutex);
        syncCV.wait(lock, [this]() { return barrierTriggered; });
        // 重置标记，准备下一次同步
        barrierTriggered = false;
    }
};

class ObjB {
private:
    std::weak_ptr<ObjA> parent;

    bool checkInternalCondition() {
        // 模拟业务条件判断
        return true;
    }

public:
    explicit ObjB(std::weak_ptr<ObjA> p) : parent(std::move(p)) {}

    void workLoop() {
        while (true) {
            // 执行任务直到满足条件
            while (!checkInternalCondition()) {
                // do work...
            }
            // 到达屏障，等待所有ObjB同步
            if (auto a = parent.lock()) {
                a->arriveAtBarrier();
            }
            // 同步完成后，继续下一轮任务
        }
    }
};

这个方案既利用了std::barrier的可靠同步能力，又通过条件变量让ObjA安全等待，同时支持动态计数和重复同步。

关于自定义忙等信号量的可行性 #

结论是：除非你有极低延迟的特殊需求（比如实时系统无法容忍上下文切换开销），否则不推荐使用忙等方案。

忙等的核心问题是会持续占用CPU时间片，当等待时间较长时，会导致CPU利用率过高，浪费系统资源；而基于std::condition_variable的阻塞等待会让线程进入睡眠状态，直到被唤醒，CPU可以被其他线程充分利用，效率高得多。

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