升级到 MacPorts gcc 7.3 后 is_lock_free() 返回 false答案

【问题标题】：is_lock_free() returned false after upgrading to MacPorts gcc 7.3升级到 MacPorts gcc 7.3 后 is_lock_free() 返回 false
【发布时间】：2018-09-23 19:19:28
【问题描述】：

以前，对于 Apple LLVM 9.1.0，128 位结构上的 is_lock_free() 已返回 true。为了获得完整的std::optional 支持，我随后升级到了 MacPorts gcc 7.3。在我第一次尝试编译时，我遇到了这个臭名昭著的 showstopper 链接器错误：

Undefined symbols for architecture x86_64:
  "___atomic_compare_exchange_16", referenced from:

我知道我可能需要添加-latomic。使用 Apple LLVM 9.1.0，我不需要它，对此我有一种非常糟糕的感觉。如果它是无锁的，您通常不需要链接到任何其他库，仅编译器就能够处理它。否则，它可能只是基于锁的，需要其他库的支持。正如我所担心的，在添加-latomic 后，构建成功，但is_lock_free() 返回false。

我确实认为 gcc 7.3 及其标准库的实现很好。这可能只是我这边的一些配置问题。事实上，我没有做任何配置。我只是安装了 MacPorts gcc 并完成了。知道我可能缺少什么吗？

【问题讨论】：

标签： c++ gcc atomic lock-free gcc7

【解决方案1】：

我自己找到了答案here。

gcc7 及更高版本将调用 libatomic 而不是内联 lock cmpxchg16b，并将从 atomic_is_lock_free (for reasons including that it's so slow it's not what users expect is_lock_free to mean) 返回 false，但至少目前 libatomic 实现仍然在该指令可用的目标上使用 lock cmpxchg16b . （它甚至可以对只读原子对象进行段错误，所以它真的不理想。）

【讨论】：

是的。 128 位无锁总是有点奇怪，因为-mcx16 需要内联lock cmpxchg16b。但显然即使在较旧的 gcc 上，如果支持，您也会在 libatomic 中获得lock cmpxchg16b，我猜是运行时 CPU 检测。 (gcc.gnu.org/ml/gcc-patches/2017-01/msg02344.html)。我没有检查；这是基于 Torvald Riegel 关于实现更改的补丁的消息中的措辞。
@PeterCordes 问题是，即使使用-mcx16，is_lock_free() 也会返回 false（未内联）。我会写一个运行时测试函数来真正检查它是否是无锁的，然后会更新答案。
我在谈论 gcc6 和更早的版本。这就是为什么我说“是”（即在那个补丁之前），但我应该在我之前的评论开始时明确表示。在 gcc6 和更早版本上，-mcx16、is_lock_free 和 is_always_lock_free 报告 16 字节对象为 true。没有-mcx16，我不确定； is_lock_free 可以在运行时检查 lock cmpxchg16b 支持。但是always_lock_free 是错误的。