Arch Linux

johannkokos

Member

Registered: 2018-02-27

Posts: 12

[Solved] C++ std::atomic is_lock_free return value different on x86_64

This talk Fedor Pikus “C++ atomics, from basic to advanced. What do they really do?” from Cppcon 2017, explains that whether struct B(see below) is lock-free depends on the hardware architecture.  On x86 it should be lock-free.

However, when I test the following code on my Arch mahcine(with i5-6500), it shows B is not lock-free. I run the the program on Debian VM on Azure(E5-2673) and it is lock-free. Can someone explain what is going on?

Edit: I run the program on arch linux docker image on Debian VM on Azure, it shows B is not lock-free. So possibly a bug?

#include <atomic>
#include <iostream>

struct A {
  long x;
};
struct B {
  long x;
  long y;
};
struct C {
  long x;
  long y;
  long z;
};

int main() {
  std::cout << std::boolalpha;

  std::atomic<A> a;
  std::cout << "A is lock-free: " << a.is_lock_free() << std::endl;

  std::atomic<B> b;
  std::cout << "B is lock-free: " << b.is_lock_free() << std::endl;

  std::atomic<C> c;
  std::cout << "C is lock-free: " << c.is_lock_free() << std::endl;

  return 0;
}

Last edited by johannkokos (2018-04-03 10:46:26)

Bevan

Member

Registered: 2009-09-08

Posts: 99

Re: [Solved] C++ std::atomic is_lock_free return value different on x86_64

I think this is a deliberate change in GCC 7 (which provides libatomic) for 16 byte data types on x86. See https://gcc.gnu.org/ml/gcc-patches/2017 … 02344.html and the linked discussion.

Some related discussion can also be found here: https://gcc.gnu.org/ml/gcc/2017-01/msg00139.html

johannkokos

Member

Registered: 2018-02-27

Posts: 12

Re: [Solved] C++ std::atomic is_lock_free return value different on x86_64

@Bevan, thanks. That's indeed caused by libatomic abi change. I update gcc6 to gcc7 on Debian vm. The result does changed.

For those who are interested in the proposed draft of abi specification, take a look at,  https://gcc.gnu.org/ml/gcc/2016-11/msg00072.html

I didn't expect the atomic library to be so tricky to deal with.