我写了一个简单的简单实现 ticket lock .锁定部分看起来像:

struct ticket {
    uint16_t next_ticket;
    uint16_t now_serving;
};

void lock(ticket* tkt) {
    const uint16_t my_ticket =
        __sync_fetch_and_add(&tkt->next_ticket, 1); 
    while (tkt->now_serving != my_ticket) {
        _mm_pause();
        __asm__ __volatile__("":::"memory");
    }   
}

struct atom_ticket {
    std::atomic<uint16_t> next_ticket;
    std::atomic<uint16_t> now_serving;
};

void lock(atom_ticket* tkt) {
    const uint16_t my_ticket =
        tkt->next_ticket.fetch_add(1, std::memory_order_relaxed);
    while (tkt->now_serving.load(std::memory_order_relaxed) != my_ticket) {
        _mm_pause();
    }   
}

 0000000000000000 <lock(ticket*)>:
    0:   b8 01 00 00 00          mov    $0x1,%eax
    5:   66 f0 0f c1 07          lock xadd %ax,(%rdi)
    a:   66 39 47 02             cmp    %ax,0x2(%rdi)
    e:   74 08                   je     18 <lock(ticket*)+0x18>
   10:   f3 90                   pause  
   12:   66 39 47 02             cmp    %ax,0x2(%rdi)
   16:   75 f8                   jne    10 <lock(ticket*)+0x10>
   18:   f3 c3                   repz retq 
   1a:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

 0000000000000020 <lock(atom_ticket*)>:
   20:   ba 01 00 00 00          mov    $0x1,%edx
   25:   66 f0 0f c1 17          lock xadd %dx,(%rdi)
   2a:   48 83 c7 02             add    $0x2,%rdi
   2e:   eb 02                   jmp    32 <lock(atom_ticket*)+0x12>
   30:   f3 90                   pause  
=> 32:   0f b7 07                movzwl (%rdi),%eax <== ???
   35:   66 39 c2                cmp    %ax,%dx
   38:   75 f6                   jne    30 <lock(atom_ticket*)+0x10>
   3a:   f3 c3                   repz retq 

最佳答案

首先，我认为你需要使用std::memory_order_acquire ，因为您正在获取锁。如果您使用 mo_relaxed ，您可能会看到前一个锁持有者所做的一些存储之前的陈旧数据。 Jeff Preshing's blog is excellent, and he has a post on release/acquire semantics .

在 x86 上，只有编译器重新排序加载和存储时才会发生这种情况，mo_relaxed告诉它允许。获取加载与 x86 上的宽松加载编译相同，但无需重新排序。每个 x86 asm 负载都已经是一个获取。在需要它的弱排序架构上，您将获得加载获取所需的任何指令。 (而在 x86 上，您只会阻止编译器重新排序)。

我放了一个版本的代码on godbolt使用各种编译器查看 asm。

很好发现，这确实看起来像 gcc 优化失败，至少在 6.0 中仍然存在(使用 Wandbox 检查，使用 main 执行 return execlp("objdump", "objdump", "-Mintel", "-d", argv[0], NULL); 转储自身的反汇编输出，包括我们感兴趣的功能.

看起来 clang 3.7 在这方面做得更糟。它执行 16 位加载，然后零扩展，然后进行比较。

gcc 专门处理原子负载，显然没有注意到它可以将其折叠到比较中。可能是在原子加载仍然与常规加载不同的情况下发生的优化传递，或者其他什么。我不是 gcc 黑客，所以这主要是猜测。

我怀疑你有一个旧的 gcc(4.9.2 或更早)，或者你正在/为 AMD 构建，因为你的编译器 used rep ret 即使与 -march=native .如果您关心生成最佳代码，您应该对此做一些事情。我注意到 gcc5 有时会编写比 gcc 4.9 更好的代码。 (虽然在这种情况下它没有帮助:/)

我尝试使用 uint32_t，但没有运气。

单独执行加载和比较对性能的影响可能无关紧要，因为该函数是一个忙等待循环。

快速路径(未锁定的情况，在第一次迭代时循环条件为假)仍然只有一个分支和一个 ret。但是，在 std:atomic 版本中，快速路径通过循环分支。因此，不是两个单独的分支预测器条目(一个用于快速路径，一个用于自旋循环)，现在自旋可能会在下一个解锁情况下导致分支预测错误。这可能不是问题，新代码确实减少了一个分支预测器条目。

如果跳入循环中间，IDK 会对英特尔 SnB 系列微架构的 uop 缓存产生任何不良影响。它有点像跟踪缓存。 Agner Fog's testing发现同一段代码如果有多个跳转入口点，在uop缓存中可以有多个入口。这个函数已经有点对 uop-cache 不友好了，因为它以 mov r, imm / lock xadd 开头。 .锁 xadd 必须自己进入一个 uop 缓存行，因为它是微编码的(超过 4 个 uops。实际上是 9 个)。无条件跳转总是结束 uop 缓存行。我不确定采用的条件分支，但我猜如果它在解码时被预测采用，则采用的 jcc 会结束缓存行。 (例如，分支预测器条目仍然很好，但旧的 uop 缓存条目已被驱逐)。

因此，第一个版本可能是用于快速路径的 3 个 uops 缓存行:一个 mov (如果已内联，希望大部分内容都包含以前的说明)，一个 lock xadd单独一个宏融合cmp/je到以下代码(如果内联。如果不是，则跳转的目标是 ret ，这可能最终成为此 32 字节代码块的第 4 个缓存行，这是不允许的。因此，此非内联版本可能始终具有每次都重新解码？)

std::atomic 版本再次是初始 mov imm 的一个 uop-cache 行。 (和前面的说明)，然后 lock xadd ，然后 add / jmp ，然后......呃哦，movzx / compare-and-branch 需要第四个缓存行欧普。因此，即使内联，此版本也更有可能出现解码瓶颈。

幸运的是，前端仍然可以在运行此代码时取得一些进展并获得排队等待 OOO 核心的指令，因为 lock xadd是 9 uop。这足以涵盖前端的一两个更少的 uop，以及解码和 uop-cache 获取之间的切换。

这里的主要问题只是代码大小，因为您有问题。想要这个内联。在速度方面，快速路径只是稍微差一点，非快速路径无论如何都是自旋循环，所以没关系。

旧版本的快速路径是 11 个融合域 uops(1 mov imm 、9 lock xadd 、1 cmp/je 宏融合)。 cmp/je包括一个微融合内存操作数。

新版本的快速路径是 41 个融合域 uops(1 mov imm、9 lock xadd、1 add、1 jmp、1 movzx、5|67 |11)。

使用 cmp/je而不是仅在 add 的寻址模式中使用 8 位偏移量真的是在脚下射击，IMO。 IDK，如果 gcc 考虑得足够远，可以做出这样的选择，让循环分支目标出现在 16B 边界，或者这只是愚蠢的运气。

使用 OP 代码对 Godbolt 进行编译器识别实验:

关于c++ - 使用原子实现票证锁会产生额外的 mov，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33284236/