使用与不使用条件变量的多线程实现差异及代码运行效果疑问

问题原因 #

你感知不到两段代码差异，是由当前测试场景的特性决定的：

• 你调用TriggerStoreCond的频率较低，两次调用间隔远大于1秒，代码2中sleep(1)带来的最大1秒响应延迟你无法直观感知
• 你使用的共享变量是简单int类型，在主流CPU架构下单次读写默认是原子操作，代码2中无锁读写共享变量的未定义行为没有触发 crash 或脏读问题
• 代码2的轮询逻辑加入了sleep(1)主动让出CPU，不会像空轮询一样占满100%CPU核心，从资源占用上你也感知不到明显差异

两段代码的核心差异 #

如果调整测试场景，差异会立刻显现：

1. 响应延迟差异
   如果把TriggerStoreCond的调用间隔调整到100ms一次，代码1会在触发后立刻唤醒工作线程执行存储逻辑，延迟在微秒级；代码2最坏需要等待1秒才会响应触发事件，1秒内的多次触发只会被合并处理一次，会出现明显的事件丢失/延迟问题。
2. 线程安全差异
   如果后续把共享变量ConfirmChanged替换为复杂结构体/多字段组合的判断条件，代码2无锁读写的逻辑会出现数据竞争，大概率读到脏数据导致逻辑异常；代码1的条件变量搭配互斥锁的逻辑，保证了共享变量读写的原子性，不会出现数据竞争问题。
3. 资源效率上限差异
   如果要降低代码2的响应延迟，只能缩短sleep的时间，比如改成10毫秒轮询一次，这时候线程的唤醒次数会大幅提升，CPU占用会明显上涨；代码1不需要轮询，工作线程在没有触发事件时会完全进入休眠状态，既可以保证极低的响应延迟，也不会额外占用CPU资源。

理解误区说明 #

你并没有对条件变量的核心作用产生误解，只是当前测试场景没有触碰到条件变量的优势边界。条件变量的核心价值就是解决「轮询方案」中响应延迟和CPU占用无法兼顾的问题，同时配合互斥锁解决共享资源的线程安全问题，这些优势只有在对延迟、并发安全、资源效率有要求的生产场景下才会直观体现。

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