std::condition_variable::wait_for和wait_until不能直接解决超时问题，因其返回timeout时无法区分真实超时与虚假唤醒，必须配合谓词使用才能安全判断条件是否满足。
std::condition_variable::wait_for 和 wait_until 为什么不能直接解决超时问题
因为 std::condition_variable::wait_for 和 wait_until 只是「等待超时」，不是「带超时的条件等待」——它们返回 cv_status::timeout 时，无法区分是超时了还是被虚假唤醒（spurious wakeup）后条件仍未满足。你得自己再检查谓词，而这个检查本身必须和互斥锁配合，否则有竞态。很多人写成：
if (cv.wait_for(lock, 100ms) == cv_status::timeout) { /* 假设条件不成立 */ }这是错的：即使超时，也可能刚巧在超时前被唤醒、但条件仍为假。正确写法：必须用带谓词的 wait_for 或 wait_until
标准库提供了带谓词的重载，它内部自动处理「唤醒→检查→继续等待或返回」的循环，且保证原子性（在锁保护下检查）。这才是安全的超时等待：
std::mutex mtx;
std::condition_variable cv;
bool ready = false;
<p>// 等待 ready 变为 true，最多等 200ms
std::unique_lock<:mutex> lock(mtx);
if (cv.wait_for(lock, 200ms, []{ return ready; })) {
// 成功：条件满足（非超时）
} else {
// 超时：lock 仍持有，ready 仍为 false
}</:mutex></p>
- 谓词必须是可调用对象，返回
bool；它会在每次唤醒后、锁仍持有的前提下被调用 - 如果谓词返回
true，函数立即返回true；如果超时且谓词始终为false，返回false - 不需要手动加
while (!ready) cv.wait_for(...)—— 谓词版本已内置该逻辑
超时时间精度与系统限制
wait_for 的实际等待时长受系统调度器和时钟精度影响，尤其在 Windows 上，std::chrono::milliseconds(1) 可能实际延迟 10–15ms。不要依赖亚毫秒级超时：
- Linux 下通常基于
CLOCK_MONOTONIC，精度较好；Windows 使用QueryPerformanceCounter，但线程调度延迟仍存在 - 避免用
wait_for(lock, 1us)—— 大部分平台会向上取整到最小调度粒度（如 1ms） - 若需高精度轮询，考虑
std::this_thread::sleep_for+ 手动检查，但注意锁竞争开销
多个条件共用一个 condition_variable 时的超时陷阱
一个 std::condition_variable 可被多个不同条件共享（比如就绪、错误、中断），但 wait_for 谓词只检查你关心的那个状态。问题在于：notify_one() 或 notify_all() 可能唤醒本不该响应的等待者，导致「误唤醒+谓词为 false+超时误判」：
- 例如：线程 A 等
data_ready，线程 B 等shutdown_requested，两者共用同一个cv - B 被唤醒后检查自己的谓词失败，继续等待；但如果 A 没有及时
notify，B 就会超时，尽管真正原因只是「没轮到它」 - 解决方案：每个独立语义的条件，尽量用独立的
std::condition_variable实例；或者在谓词中显式排除无关事件（如[]{ return data_ready && !shutdown_requested; }）
超时逻辑本身很简单，难的是厘清「谁该唤醒谁」「唤醒是否意味着条件真满足」——这取决于你的同步协议设计，而不是 wait_for 能替你决定的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
