封装std::condition_variable的Wrapper类是否正确？是否为最佳实践？STL有无替代？

在使用std::condition_variable实现线程等待场景时，常见模式需要手动管理互斥锁、条件变量和条件值，有人封装了CVWaiter模板类简化代码，现提出三个问题：

1. 这个CVWaiter类的实现是否正确？
2. 在此类线程等待场景中使用封装类是否为良好实践？
3. STL中是否已有更简便的方案实现相同功能？

一、CVWaiter类的实现是否正确？ #

这个实现存在多个编译和跨平台问题，并非正确的标准C++实现：

1. 构造函数名称不匹配：类名为CVWaiter，但构造函数写为Waiter，直接导致编译失败，需改为CVWaiter。
2. 非标准宏使用：_In_是微软特定的SAL注解，不属于标准C++，跨平台编译时必须移除。
3. 模板实例化错误：示例中CVWaiter workDoneWaiter(false);缺少模板参数，标准C++要求显式指定CVWaiter<bool> workDoneWaiter(false);，否则编译不通过。
4. 通知时机的风格问题：当前实现先解锁再调用notify_all()，虽然不影响正确性，但标准推荐持有锁时通知（确保条件状态已稳定），不过这属于代码风格而非正确性问题。
5. 异常安全性：这部分是安全的，std::unique_lock的RAII特性会在update函数抛出异常时自动释放锁。

修正后的核心构造函数示例：

CVWaiter(const T& val) : m_val(val)
{
}

二、使用此类封装是否为良好实践？ #

是，但需把握封装边界：

• 核心优点：
  • 减少重复代码：避免手动编写锁、条件变量逻辑时的常见错误（如忘记在锁保护下修改条件、漏解锁）。
  • 提升可读性：调用方只需关注条件的更新与等待逻辑，无需关心底层同步细节。
  • 增强可维护性：若需调整同步逻辑（如替换为std::condition_variable_any），仅需修改封装类，无需改动所有调用点。
• 注意事项：
  • 避免过度封装：如果只是单一简单场景（如仅等待布尔值完成），封装收益有限；但多场景复用的情况下，封装价值显著。
  • 保持单一职责：此类仅负责同步等待与条件更新，不要添加无关功能，避免类臃肿。

三、STL中是否有更简便的方案？ #

STL提供了多个更贴合场景的标准工具，无需手动封装：

1. std::future + std::promise（C++11及以上）
   若仅需等待线程完成任务（或获取任务结果），这是最简便的方案，完全无需手动管理条件变量与互斥锁：

   // 工作线程侧
   std::promise<void> workPromise;
   auto workFuture = workPromise.get_future();
   
   // 工作线程完成任务后触发
   workPromise.set_value();
   
   // 等待线程侧
   workFuture.wait();
   

   若需返回结果，可使用std::promise<int>等类型，通过workFuture.get()直接获取结果。

2. std::latch/std::barrier（C++20及以上）
   针对多线程等待单一事件完成的场景，std::latch是一次性同步工具，使用极为简洁：

   std::latch workLatch(1); // 初始计数器为1
   
   // 工作线程完成任务后递减计数器
   workLatch.count_down();
   
   // 等待线程阻塞直到计数器归0
   workLatch.wait();
   

   若需重复使用同步逻辑，可替换为std::barrier。

这些标准工具经过官方优化与验证，比手动封装的CVWaiter更可靠、简洁，优先推荐使用。

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