启用辅助线程后缓存延迟异常升高的原因排查

你的测试结果显示启用辅助线程后缓存读延迟从25ns升至46ns，超出预期的Shared(S)状态下的性能，核心原因并非触发了Invalidate(I)状态转换，而是以下几个硬件层面的细节导致：

1. Shared状态下的缓存读存在额外验证开销 #

虽然MESI/MESIF协议中Shared状态允许核心直接读取本地L1缓存，但Intel CPU的缓存一致性硬件在处理多核心共享的缓存行时，会增加额外的验证逻辑：

• 当核心1将缓存行从Exclusive(E)转为Shared(S)并发送给核心2后，核心1的L1缓存中该行会被标记为“多核心共享”，后续读操作需要通过**窥探过滤器(Snoop Filter)**确认其他核心未修改该行，这个验证过程会带来数ns到十几ns的延迟。
• 单线程场景下缓存行始终处于Exclusive状态，无需额外验证，读操作直接从L1取，延迟更低。

2. 内存屏障(_mm_mfence)的同步开销被放大 #

你的计时逻辑包含了两次_mm_mfence和原子读操作：

• 单线程场景下，mfence仅需等待本地内存操作完成，开销稳定。
• 多线程场景下，辅助线程的读操作触发了跨核心的缓存一致性事务，mfence需要等待所有这些同步事务完全结束才能继续，这会显著增加mfence的执行时间，最终拉高整体计时结果。

3. 核心间缓存同步的残留延迟 #

即使主线程等待辅助线程完成读操作并设置ready=false，CPU的缓存控制器或Ring总线可能仍有未完全收尾的一致性流量（比如窥探确认信号），主线程的读操作需要等待这些残留事务结束才能执行，进一步增加了延迟。

验证方法 #

你可以通过性能计数器工具确认具体原因：

# 单线程场景统计缓存事件
perf stat -e cache-misses,L1-dcache-loads,bus-cycles ./load_test 10000 0

# 多线程场景统计缓存事件
perf stat -e cache-misses,L1-dcache-loads,bus-cycles ./load_test 10000 1

如果多线程场景下bus-cycles显著增加，说明总线一致性事务是延迟的主要来源；如果cache-misses上升，可能是缓存行被意外驱逐（但你的padding已经排除伪共享，这种概率极低）。

结论 #

并未触发Invalidate(I)状态转换——辅助线程仅执行读操作，不会修改缓存行状态。额外延迟来自多核心共享缓存行时的硬件验证逻辑、内存屏障的同步开销，以及缓存一致性事务的残留延迟。

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