为何gcc未生成fence指令？自旋锁的内存屏障何在？

实验背景与代码 #

我正在基于C11内存模型，使用stdatomic.h及面向现代x86-64 Intel CPU的最新稳定版gcc开展实验。

C11自旋锁代码 #

void lock(struct spinlock_t *sl) {
  while (atomic_exchange_explicit(&__sl.taken, 1, memory_order_acquire))
    while (atomic_load_explicit(&__sl.taken, memory_order_relaxed))
      __asm volatile("pause" ::: "memory");
}

-O3编译后的汇编代码 #

0000000000001370 <lock>:
    1370:   f3 0f 1e fa             endbr64 
    1374:   ba 01 00 00 00          mov    $0x1,%edx
    1379:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)
    1380:   48 89 d0                mov    %rdx,%rax
    1383:   48 87 05 8e 2c 00 00    xchg   %rax,0x2c8e(%rip)        # 4018 <__sl>
    138a:   48 85 c0                test   %rax,%rax
    138d:   74 11                   je     13a0 <lock+0x30>
    138f:   90                      nop
    1390:   48 8b 05 81 2c 00 00    mov    0x2c81(%rip),%rax        # 4018 <__sl>
    1397:   48 85 c0                test   %rax,%rax
    139a:   74 e4                   je     1380 <lock+0x10>
    139c:   f3 90                   pause  
    139e:   eb f0                   jmp    1390 <lock+0x20>
    13a0:   c3                      ret      

疑问 #

pause指令符合预期，但未生成fence指令，请问内存屏障在哪里？该汇编如何保证顺序一致性？

解答 #

内存屏障的来源：xchg指令的天然特性 #

在x86-64架构的Intel规范中，xchg指令**本身就隐含了全内存栅栏（full memory fence）**的效果，等价于显式执行mfence指令，不需要额外生成独立的fence指令。

你的C代码中，atomic_exchange_explicit指定了memory_order_acquire语义，gcc针对x86-64平台会直接将其映射为xchg指令——因为xchg的天然屏障已经完全满足acquire的内存顺序要求，甚至提供了更强的全栅栏保障。

顺序一致性的保证逻辑 #

1. 锁获取阶段的顺序保障
   当xchg指令成功获取锁（返回值为0），它的全栅栏特性会强制：

   • 所有在临界区内的内存访问，不会被CPU重排到xchg指令之前；
   • 其他线程释放锁时的内存操作（比如带memory_order_release语义的原子存储），其修改会被当前线程的缓存同步感知到，确保临界区能看到锁释放前的所有内存更新。

2. 自旋等待阶段的无屏障合理性
   内层循环用memory_order_relaxed加载__sl.taken，这里不需要额外内存屏障：

   • 它只是单纯轮询锁的状态，没有其他内存操作的顺序依赖；
   • pause指令的作用是告知CPU当前处于自旋等待状态，减少乱序执行的资源开销，同时避免投机性内存访问引发的缓存一致性风暴，不会影响内存顺序。

3. 架构层面的缓存一致性
   x86-64平台的MESI缓存一致性协议，会自动保证多线程间缓存状态的同步。结合xchg的内存栅栏，完全满足C11自旋锁所需的顺序一致性要求。

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