伪共享开销周期数及多线程数据访问相关技术咨询

一、多线程访问同一数据的性能损耗 #

1. 单次修改单个变量的损耗 #

• x86-64（Coffee Lake/Zen2）：无竞争时，atomic_relaxed这类轻量原子操作的加载/存储开销接近普通变量——加载约3-5周期，存储约10-15周期（缓存命中场景）。若多线程竞争同一缓存行，会触发MESI缓存一致性协议的状态切换：写入核心将缓存行置为独占/修改态，其他核心的对应缓存行失效，后续读取需重新从写入核心缓存或内存加载，单次竞争修改的延迟可能飙升至50-200周期（取决于跨核心通信距离）。
• Mac M2（ARMv8.5+）：采用MOESI协议，无竞争时原子操作开销略高于普通变量（加载约4-6周期，存储约12-18周期）；竞争场景下，跨核心缓存同步延迟约40-180周期，整体趋势与x86接近。

2. 缓存行已加载时其他核心的行为 #

其他核心不会“立即停滞”，仅在下次访问该缓存行时才会感知到失效：

• 核心修改缓存行时，会通过嗅探总线发送失效通知，但不会打断其他核心的当前指令流；只有当其他核心的指令尝试访问该失效缓存行时，才会进入等待状态并发起缓存行请求。
• 缓存行更新耗时：x86同插槽内核心间约30-50周期，跨插槽约100-200周期；M2大核之间约25-40周期，大核与小核之间约50-80周期。

二、伪共享与TLB问题 #

1. 伪共享的触发条件 #

伪共享并非仅发生在128字节以内：

• x86-64（Coffee Lake/Zen2）和Mac M2的缓存行大小均为64字节，只要两个线程访问的变量处于同一64字节缓存行，且至少有一个线程执行写入操作，就会触发伪共享。你的场景中，状态标志在对象前64字节内，若其他线程同时访问该缓存行内的相邻字节且存在写入，必然引发伪共享，导致频繁的缓存行失效与同步。

2. TLB问题 #

无需过度担心TLB问题：

• 1K个对象的虚拟地址对应物理页数量有限，现代CPU的TLB容量（如Coffee Lake的L2 TLB支持最多2048个4KB页条目，M2 TLB容量更大）完全能覆盖。即使出现TLB miss，单次开销约20-50周期，仅在首次访问时发生，相对于缓存一致性开销可忽略。

三、原子操作与指针方案的选择 #

1. atomic_relaxed的适用性 #

完全匹配你的场景需求：

• 由于其他线程无需感知标志更新（仅设置无关位），atomic_relaxed的内存语义足够——仅保证操作原子性，不提供额外内存序约束，是开销最低的原子操作，不会引入多余内存栅栏指令，能有效控制内存带宽占用，同时解决线程sanitizer的竞态告警。

2. 指针更新方案的风险 #

直接用普通指针非原子更新数据，即使读取线程在10ns内访问，也会存在严重问题：

• 非原子写入可能被CPU指令重排、缓存延迟影响，导致读取线程看到部分更新的32位标志（撕裂读取），甚至完全看不到写入操作（缓存未同步），属于未定义行为，远比重性能损耗更严重。
• 若1K个对象各写入一次，读取线程大概率触发缓存行失效，每个对象的读取停滞周期约30-80周期（同核心组内），总开销远高于atomic_relaxed。

3. 内存带宽优化建议 #

• 若对象大小不足64字节，可将状态标志与其他非多线程访问数据分离，或用**缓存行填充（padding）**让标志独占一个64字节缓存行，避免伪共享带来的频繁缓存同步，减少内存总线流量。
• 优先使用atomic_relaxed而非atomic_seq_cst等更重的原子语义，避免内存栅栏指令的额外带宽消耗。

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