这篇文章主要讲解了“C++11中的原子量和内存序有什么用”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“C++11中的原子量和内存序有什么用”吧！

一、多线程下共享变量的问题

(a) i++问题

在多线程编程中，最常拿来举例的问题便是著名的i++ 问题，即：多个线程对同一个共享变量i执行i++ 操作。这样做之所以会出现问题的原因在于i++这个操作可以分为三个步骤：

上面三个步骤中间是可以间隔的，并非原子操作，也就是说多个线程同时执行的时候可能出步骤的交叉执行，例如下面的情况：

假设i一开始为0，则执行完第4步后，在两个线程都认为寄存器中的值为1，然后在第5、6两步分别写回去。最终两个线程执行完成后i的值为1。但是实际上我们在两个线程中执行了i++，原本希望i的值为2。i++ 实际上可以代表多线程编程中由于操作不是原子的而引发的交叉执行这一类的问题，但是在这里我们先只关注对单个变量的操作。

(b)指令重排问题

有时候，我们会用一个变量作为标志位，当这个变量等于某个特定值的时候就进行某些操作。但是这样依然可能会有一些意想不到的坑，例如两个线程以如下顺序执行：

当B判断flag为true后，断言a为1，看起来的确是这样。那么一定是这样吗？可能不是，因为编译器和CPU都可能将指令进行重排（编译器不同等级的优化和CPU的乱序执行）。实际上的执行顺序可能变成这样：

这种重排有可能会导致一个线程内相互之间不存在依赖关系的指令交换执行顺序，以获得更高的执行效率。比如上面：flag 与 a 在A线程看起来是没有任何依赖关系，似乎执行顺序无关紧要。但问题在于B使用了flag作为是否读取a的依据，A的指令重排可能会导致step3的时候断言失败。

解决方案

一个比较稳妥的办法就是对于共享变量的访问进行加锁，加锁可以保证对临界区的互斥访问，例如第一种场景如果加锁后再执行i++ 然后解锁，则同一时刻只会有一个线程在执行i++ 操作。另外，加锁的内存语义能保证一个线程在释放锁前的写入操作一定能被之后加锁的线程所见（即有happens before 语义），可以避免第二种场景中读取到错误的值。

那么如果觉得加锁操作过重太麻烦而不想加锁呢？C++11提供了一些原子变量与原子操作来支持。

二、 C++11的原子量

C++11标准在标准库atomic头文件提供了模版atomic<>来定义原子量：

template< class T >
struct atomic;

它提供了一系列的成员函数用于实现对变量的原子操作，例如读操作load，写操作store，以及CAS操作compare_exchange_weak/compare_exchange_strong等。而对于大部分内建类型，C++11提供了一些特化：

std::atomic_bool std::atomic
std::atomic_char std::atomic
std::atomic_schar std::atomic
std::atomic_uchar std::atomic
std::atomic_short std::atomic
std::atomic_ushort std::atomic
std::atomic_int std::atomic
std::atomic_uint std::atomic
std::atomic_long std::atomic
······
//更多类型见：http://en.cppreference.com/w/cpp/atomic/atomic

实际上这些特化就是相当于取了一个别名，本质上是同样的定义。而对于整形的特化而言，会有一些特殊的成员函数，例如原子加fetch_add、原子减fetch_sub、原子与fetch_and、原子或fetch_or等。常见操作符++、--、+=、&= 等也有对应的重载版本。

接下来以int类型为例，解决我们的前面提到的i++ 场景中的问题。先定义一个int类型的原子量：

std::atomic i;

由于int型的原子量重载了++ 操作符，所以i++ 是一个不可分割的原子操作，我们用多个线程执行i++ 操作来进行验证，测试代码如下:

#include 
#include 
#include 
#include 
#include 

std::atomic i;
const int count = 100000;
const int n = 10;

void add()
{
 for (int j = 0; j < count; ++j)
 i++;
}

int main()
{
 i.store(0);
 std::vector workers;
 std::cout << "start " << n << " workers, "
  << "every woker inc " << count << " times" << std::endl;

 for (int j = 0; j < n; ++j)
 workers.push_back(std::move(std::thread(add)));

 for (auto & w : workers)
 w.join();

 std::cout << "workers end "
  << "finally i is " << i << std::endl;

 if (i == n * count)
 std::cout << "i++ test passed!" << std::endl;
 else
 std::cout << "i++ test failed!" << std::endl;

 return 0;
}

在测试中，我们定义了一个原子量i，在main函数开始的时候初始化为0，然后启动10个线程，每个线程执行i++操作十万次，最终检查i的值是否正确。执行的最后结果如下：

start 10 workers, every woker inc 100000 times
workers end finally i is 1000000
i++ test passed!

上面我们可以看到，10个线程同时进行大量的自增操作，i的值依然正常。假如我们把i修改为一个普通的int变量，再次执行程序可以得到结果如下：

start 10 workers, every woker inc 100000 times
workers end finally i is 445227
i++ test failed!

显然，由于自增操作各个步骤的交叉执行，导致最后我们得到一个错误的结果。

原子量可以解决i++问题，那么可以解决指令重排的问题吗？也是可以的，和原子量选择的内存序有关，我们把这个问题放到下一节专门研究。

上面已经看到atomic是一个模版，那么也就意味着我们可以把自定义类型变成原子变量。但是是否任意类型都可以定义为原子类型呢？当然不是，cppreference中的描述是必须为TriviallyCopyable类型。这个连接为TriviallyCopyable的详细定义：

http://en.cppreference.com/w/cpp/concept/TriviallyCopyable

一个比较简单的判断标准就是这个类型可以用std::memcpy按位复制，例如下面的类：

class {
 int x;
 int y;
}

这个类是一个TriviallyCopyable类型，然而如果给它加上一个虚函数：

class {
 int x;
 int y;
 virtual int add ()
 {
  return x + y;
 }
}

这个类便不能按位拷贝了，不满足条件，不能进行原子化。

如果一个类型能够满足atomic模版的要求，可以原子化，它就不用进行加锁操作了，因而速度更快吗？依然不是，atomic有一个成员函数is_lock_free，这个成员函数可以告诉我们到底这个类型的原子量是使用了原子CPU指令实现了无锁化，还是依然使用的加锁的方式来实现原子操作。不过不管是否用锁来实现，atomic的使用方式和表现出的语义都是没有区别的。具体用哪种方式实现C++标准并没有做约束（除了std::atomic_flag特化要求必须为lock free），跟平台有关。

例如在我的Cygwin64、GCC7.3环境下执行如下代码：

#include 
#include 

#define N 8

struct A {
 char a[N];
};

int main()
{
 std::atomic a;
 std::cout << sizeof(A) << std::endl;
 std::cout << a.is_lock_free() << std::endl;
 return 0;
}

结果为：

8
1

证明上面定义的类型A的原子量是无锁的。我在这个平台上进行了实验，修改N的大小，结果如下：

将A修改为内建类型，对于内建类型的实验结果如下：

可以看出在我的平台下常用内建类型都是lock free的，自定义类型则和大小有关。

从上面的统计还可以看出似乎当自定义类型的长度和某种自定义类型相等的时候is_lock_free()就为true。我推测可能我这里的atomic实现的无锁是通过编译器内建的原子操作实现的，只有当数据长度刚好能调用编译器内建原子操作时才能进行无锁化。查看GCC参考手册（/tupian/20230522/_005f_005fatomic-Builtins.html 中内建原子操作的原型，以CAS操作为例：

bool __atomic_compare_exchange_n (type *ptr, type *expected, type desired, bool weak, int success_memorder, int failure_memorder)

bool __atomic_compare_exchange (type *ptr, type *expected, type *desired, bool weak, int success_memorder, int failure_memorder)

其参数类型为type *的指针，在同一页可以找到GCC关于type的描述：

The ‘__atomic' builtins can be used with any integral scalar or pointer type that is 1, 2, 4, or 8 bytes in length. 16-byte integral types are also allowed if ‘__int128' (see __int128) is supported by the architecture.

type类型的长度应该为1、2、4、8字节中的一个，少数支持__int128的平台可以到16字节，所以只有长度为1，2，4，8字节的数据才能实现无锁。这个只是我的推测，具体是否如此尚不明白。

三、C++11的六种内存序

typedef enum memory_order {
 memory_order_relaxed,
 memory_order_consume,
 memory_order_acquire,
 memory_order_release,
 memory_order_acq_rel,
 memory_order_seq_cst
} memory_order;