在gcc 4.7.2中，std::atomic<T>中未定义is_lock_free？

Question

我在Linux上使用gcc 4.7.2编译以下代码时，遇到了以下编译器错误：

function std::atomic::is_lock_free() const: error: undefined reference 
to '__atomic_is_lock_free' 

struct S {
  int a;
  int b;
};


  std::atomic<S> s;
  cout << s.is_lock_free() << endl;

- Derek

---

不太可能让你高兴，但是：它似乎在gcc 4.8和ICC 13上工作。 - us2012

@us2012，对于用户定义的POD类型，std::atomic<S>是标准的还是GCC扩展？cppreference只说明“完全特化”定义了原子类型，并提供了“以下完全特化”。 - Stephen Lin

如果类型 T 大小足够小以便使用硬件原子指令处理（通常不大于最大整数类型），那么 atomic<T> 可以是无锁的。 - Pete Becker

我在使用gcc 4.7.3的基于嵌入式ARM Linux代码库时遇到了完全相同的情况。作为一种解决方法，我目前正在使用一个union将类似您的结构体包装在一个64位整数中以强制执行所需的行为，结果证明is_lock_free()提供了解决方法。 - notlesh

结果看起来类似于：联合体Foo { long long int s; 结构体S { int a; int b; }}; - notlesh

Answer 1

GCC 4.7中的原子API不完整:

• 当没有无锁指令可用（无论是通过硬件还是操作系统支持）时，原子操作被留作函数调用以由库解决。由于时间限制和未最终确定的API，GCC 4.7没有提供libatomic。这可以通过遇到以__atomic_*开头的未满足的外部符号来轻松确定。

由于GCC 4.7没有提供libatomic，您需要使用另一个实际支持所需功能或提供缺少功能的编译器（示例实现）。

- Zeta

---

gcc 的开发人员提供了一个 libatomic 的示例实现，可以在链接到你引用的段落下方的这个链接中找到：http://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile&do=view&target=libatomic.c。它可以与其他无法使用 gcc4.7 编译的程序一起编译和链接。（不过对于这个实现的效率和正确性我不太清楚。） - us2012