std::condition_variable 的信号丢失问题
内容提要
这篇文章讨论了在退出阶段中可能出现的长时间等待的问题。作者提出了两种解决方案，一种是加入额外的锁来保护关键变量，另一种是缩短等待时间后重试。作者选择了后一种方案，并表示已经合并到项目中。此外，文章还提到了与线程安全相关的问题，并提出了解决方法。
延伸解读
信号丢失的根源：条件变量的检查与等待间隙
文章指出，std::condition_variable::wait_for 的谓词检查与进入等待之间存在一个极小的窗口。若通知恰在此窗口内发出，等待线程将错过唤醒，导致不必要的长时间阻塞。在退出阶段，后台线程已终止，不会再次通知，因此等待只能依赖超时。这解释了为何 ForceFlush 偶尔会卡住。
两种修复方案的权衡：加锁与缩短超时
作者提出两种方案：一是引入额外互斥锁，将标志、条件变量和等待操作纳入同一临界区，彻底消除竞争，但增加开销；二是缩短等待时间后重试，不引入新锁，但可能多等一个短超时。考虑到问题仅在退出阶段小概率出现，作者选择了后者，并已合并到项目中。
多线程调用 ForceFlush 的隐藏风险
文章后续提到，is_force_flush_notified 是 atomic bool，当多个线程同时调用 ForceFlush 时，一个线程可能吞掉另一个线程的通知，导致某个线程永远等待。社区已收到相关 issue，解决方案是改用 exported 序号来判定多次调用的先后关系，替代简单的 bool 标志。
Q&A
std::condition_variable 的信号丢失问题是什么？
信号丢失问题发生在进程优雅退出时，后台线程完成数据导出后可能未能及时通知主线程，导致主线程长时间等待。
在处理信号丢失问题时，作者提出了哪些解决方案？
作者提出了两种解决方案：增加额外的锁来保护关键变量，或缩短等待时间后重试。最终选择了后者。
为什么在调用 ForceFlush() 时会出现长时间等待的情况？
长时间等待可能是因为在后台线程设置通知标志后，主线程已经进入等待状态，导致未能及时收到通知。
使用 std::condition_variable 时可能遇到哪些线程安全问题？
使用 atomic bool 值可能导致多线程调用时的竞争，某些线程的通知状态可能被其他线程覆盖。
作者选择缩短等待时间后重试的方案有什么优缺点？
优点是避免了额外的锁开销，缺点是可能需要额外等待时间才能完成操作。
在项目中如何优雅退出以避免信号丢失问题？
在优雅退出时，需确保后台线程完成数据导出并及时通知主线程，避免长时间等待。
