gcc 的原子操作和代码生成

我正在查看 gcc 为原子操作生成的一些程序集。我尝试了以下简短的序列：

int x1;
int x2;

int foo;

void test()
{
  __atomic_store_n( &x1, 1, __ATOMIC_SEQ_CST );
  if( __atomic_load_n( &x2  ,__ATOMIC_SEQ_CST ))
    return;

  foo = 4;
}

看看 Herb Sutter 关于代码生成的原子武器演讲，他提到 X86 手册要求使用xchg对于原子商店和一个简单的mov用于原子读取。所以我期待一些类似的事情：

test():
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    $1, %eax
    xchg    %eax, x1(%rip)
    movl    x2(%rip), %eax
    testl   %eax, %eax
    setne   %al
    testb   %al, %al
    je      .L2
    jmp     .L1
.L2:
    movl    $4, foo(%rip)
.L1:
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc

由于锁定，内存栅栏是隐式的xchg操作说明。

但是如果我使用编译它gcc -march=core2 -S test.cc我得到以下信息：

test():
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    $1, %eax
    movl    %eax, x1(%rip)
    mfence
    movl    x2(%rip), %eax
    testl   %eax, %eax
    setne   %al
    testb   %al, %al
    je      .L2
    jmp     .L1
.L2:
    movl    $4, foo(%rip)
.L1:
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc

所以不要使用xchg操作 gcc 这里使用mov + mfence组合。这种代码生成与 Herb Sutter 所说的 x86 架构所要求的不同的原因是什么？

The xchg当目标是内存位置时，指令具有隐含的锁定语义。这意味着您可以自动交换寄存器的内容与内存位置的内容。

问题中的示例是进行原子存储，而不是交换。 x86 架构内存模型保证在多处理器/多核系统中，一个线程完成的存储将按该顺序被其他线程看到......因此内存移动就足够了。话虽如此，有些较旧的 Intel CPU 和一些克隆产品在这方面存在错误，并且xchg需要作为这些 CPU 上的解决方法。请参阅这篇关于自旋锁的维基百科文章的重要优化部分：

http://en.wikipedia.org/wiki/Spinlock#Example_implementation

哪个州

上面的简单实现适用于所有使用 x86 架构的 CPU。但是，可以进行许多性能优化：

在 x86 架构的后续实现中，spin_unlock 可以安全地使用未锁定的 MOV，而不是较慢的锁定 XCHG。这是由于支持这一点的微妙内存排序规则，即使 MOV 不是完整的内存屏障。但是，某些处理器（某些 Cyrix 处理器、Intel Pentium Pro 的某些修订版（由于错误）以及早期的 Pentium 和 i486 SMP 系统）会执行错误操作，并且受锁保护的数据可能会损坏。在大多数非 x86 体系结构上，必须使用显式内存屏障或原子指令（如示例中所示）。在某些系统上，例如 IA-64，有特殊的“解锁”指令来提供所需的内存排序。

记忆障碍，mfence，确保所有存储已完成（CPU 内核中的存储缓冲区为空，值存储在高速缓存或内存中），它还确保未来的加载不会乱序执行。

MOV 足以解锁互斥体（不需要序列化或内存屏障）这一事实已在 1999 年 Intel 架构师回复 Linus Torvalds 时“正式”澄清

http://lkml.org/lkml/1999/11/24/90.

我想后来发现它不适用于某些较旧的 x86 处理器。