C++标准同步构造超时功能差异：为何latch等无wait_for？

需求与现有工具的局限 #

要一次性等待多个线程完成任务，std::latch是最贴合的选择——等待线程调用wait()，工作线程完成后调用count_down()。但如果需要超时等待，std::latch却没有wait_for/wait_until接口；std::semaphore虽支持超时等待，但其语义逻辑相反：初始计数不能为负（前置条件desired >= 0），无法直接模拟latch“等待计数归0”的逻辑；std::atomic的wait()能解决不少同步场景，但同样缺少定时等待能力，最终只能用std::condition_variable配合std::mutex自行实现带超时的latch。

部分原语不支持超时的原因 #

这背后主要有两方面考量：

• 场景定位与设计优先级：std::latch、std::barrier这类原语被设计为一次性/固定阶段的同步点，标准委员会最初认为它们的典型使用场景（比如程序启动时等待初始化线程完成、批量任务结束后的统一汇合）不需要“超时放弃”逻辑，因此未优先加入超时接口。
• 实现复杂度与平台兼容性：原子操作的定时等待（如std::atomic的wait_for）需要底层硬件和操作系统的高效支持，早期C++标准制定时，并非所有平台都能提供成熟的原子变量定时阻塞能力；而std::condition_variable、std::semaphore的超时逻辑依赖操作系统线程调度机制，实现更成熟，因此先提供了超时接口。

现状与未来 #

你提到的P2643提案确实已针对C++26提出std::atomic的定时等待API，包括try_wait()、wait_for()和wait_until()，填补了原子等待的超时能力空白。另外，原子等待支持进程间共享内存确实是极具价值的方向——若实现，跨进程同步可摆脱对重量级IPC机制的依赖，效率会大幅提升。

临时替代方案：自行实现带超时的latch #

如果需要在C++20或更早版本中使用带超时的latch，用std::condition_variable和std::mutex的实现并不复杂：

#include <condition_variable>
#include <mutex>
#include <atomic>
#include <chrono>

class timed_latch {
public:
    explicit timed_latch(std::ptrdiff_t count) : m_count(count) {}

    void count_down() {
        if (--m_count == 0) {
            std::lock_guard<std::mutex> lock(m_mutex);
            m_cv.notify_all();
        }
    }

    template <typename Rep, typename Period>
    bool wait_for(const std::chrono::duration<Rep, Period>& timeout) {
        std::unique_lock<std::mutex> lock(m_mutex);
        return m_cv.wait_for(lock, timeout, [this]() { return m_count == 0; });
    }

private:
    std::atomic<std::ptrdiff_t> m_count;
    std::mutex m_mutex;
    std::condition_variable m_cv;
};

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