x86/amd64自旋锁释放无需冲刷存储缓冲区的原因及正确性分析

核心结论 #

s200的断言100%成立，不存在s100获取到锁时x的更新未对thread2可见的情况。这个正确性是x86/amd64架构的TSO（Total Store Order，总存储序）内存模型的硬性保证，和存储缓冲区冲刷时长、函数调用开销没有任何关联。

为什么锁释放不需要冲刷存储缓冲区？ #

x86 TSO模型对内存操作重排做了严格限制，刚好匹配自旋锁的同步语义：

• 禁止StoreStore重排：同一核心的所有写操作，对其他核心可见的顺序和程序编写顺序完全一致。thread1中s2 x=100的写操作，一定早于s3 写入mylock释放锁的写操作被所有其他核心观测到。
• 锁获取操作（带LOCK前缀的cmpxchg）天然满足acquire语义，保证锁获取成功后的所有读写操作，不会被重排到锁获取操作之前；而普通MOV写操作释放锁天然满足release语义，保证锁释放之前的所有读写操作都完成并对其他核心可见后，才会执行锁释放的写入。
• 哪怕x的更新还在thread1的存储缓冲区里没有提交到缓存，x86的总线嗅探机制也会让thread2的读操作直接拿到存储缓冲区里的最新值，不需要等缓冲区刷到缓存。

两个疑问解答 #

1. pthread_spin_unlock的函数调用开销是否能覆盖存储缓冲区冲刷时间？ #

完全不需要依赖这种时间巧合。哪怕pthread_spin_unlock被编译器内联为单条MOV指令，没有任何函数调用开销，上述的内存序保证依然成立，正确性不受任何影响。

2. 带LOCK前缀的指令是否会自动冲刷其他核心的存储缓冲区？ #

不会。LOCK前缀的指令只会冲刷当前执行指令核心的存储缓冲区，同时禁止该指令前后的内存操作重排，保证原子读改写操作的全局一致性。不需要冲刷其他核心的存储缓冲区，缓存一致性协议会自动处理核心间的可见性同步。

弱内存序架构的最低成本修复方案 #

你描述的场景在x86/amd64下不需要任何修复，原生的MOV释放锁就完全正确。如果是ARM、RISC-V这类弱内存序架构，最低成本的修复方案是在释放锁的MOV指令前加一条release语义的轻量屏障：

• 不需要插入mfence这类全屏障，x86下mfence开销远高于普通MOV，完全没必要
• 不需要把MOV替换为原子读改写指令，这类指令默认带LOCK前缀，开销比普通MOV高很多

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