std::condition_variable 的信号丢失问题
💡
原文中文，约6900字，阅读约需17分钟。
📝
内容提要
这篇文章讨论了在退出阶段中可能出现的长时间等待的问题。作者提出了两种解决方案，一种是加入额外的锁来保护关键变量，另一种是缩短等待时间后重试。作者选择了后一种方案，并表示已经合并到项目中。此外，文章还提到了与线程安全相关的问题，并提出了解决方法。
🎯
关键要点
- 文章讨论了在退出阶段中可能出现的长时间等待问题。
- 问题源于项目组接入 opentelemetry-cpp 时的超时现象。
- 在进程优雅退出时，需等待后台线程完成事件执行。
- 使用 std::condition_variable 来通知事件完成。
- 在 ForceFlush 方法中，可能会出现长时间等待的情况。
- 后台线程在完成数据导出后会设置通知标志，但可能会在退出时导致通知丢失。
- 提出两种解决方案：增加额外锁或缩短等待时间后重试。
- 选择了缩短等待时间后重试的方案，已合并到项目中。
- 提到线程安全问题，使用 atomic bool 值可能导致多线程调用时的竞争。
- 社区已收到相关问题，提出使用 exported 序号来替代 bool 值判定。
❓
延伸问答
std::condition_variable 的信号丢失问题是什么？
信号丢失问题发生在进程优雅退出时，后台线程完成数据导出后可能未能及时通知主线程，导致主线程长时间等待。
在处理信号丢失问题时，作者提出了哪些解决方案？
作者提出了两种解决方案：增加额外的锁来保护关键变量，或缩短等待时间后重试。最终选择了后者。
为什么在调用 ForceFlush() 时会出现长时间等待的情况？
长时间等待可能是因为在后台线程设置通知标志后，主线程已经进入等待状态，导致未能及时收到通知。
使用 std::condition_variable 时可能遇到哪些线程安全问题？
使用 atomic bool 值可能导致多线程调用时的竞争，某些线程的通知状态可能被其他线程覆盖。
作者选择缩短等待时间后重试的方案有什么优缺点？
优点是避免了额外的锁开销，缺点是可能需要额外等待时间才能完成操作。
在项目中如何优雅退出以避免信号丢失问题？
在优雅退出时，需确保后台线程完成数据导出并及时通知主线程，避免长时间等待。
➡️
