【C++ 多线程那些事儿】多线程的执行顺序如你预期吗？

一个简单的例子

先来看一个多线程的例子：

如图所示，我们将变量 x 和 y 初始化为 0，然后在线程 1 中执行：

x = 1, m = y;

同时在线程 2 中执行:

y = 1, n = x;

当两个线程都执行结束以后，m 和 n 的值分别是多少呢？

对于已经工作了 n 年、写过无数次并发程序的的我们来说，这还不是小 case 吗？让我们来分析一下，大概有三种情况：

1. 如果程序先执行了 x = 1, m = y 代码段，后执行了 y = 1, n = x 代码段，那么结果是 m = 0, n = 1;

2. 如果程序先执行了 y = 1, n = x 代码段，后执行了 x = 1, m = y 代码段，那么结果是 m = 1, n = 0;

3. 如果程序的执行顺序先是 x = 1, y = 1, 后执行 m = y, n = x, 那么结果是 m = 1, n = 1;

所以(m, n)的组合一共有 3 种情况，分别是(0, 1), (1, 0)和(1, 1)。

那有没有可能程序执行结束后，(m, n)的值是(0, 0)呢？嗯...我们又仔细的回顾了一下自己的分析过程：在 m 和 n 被赋值的时候，x = 1 和 y = 1 至少有一条语句被执行了...没有问题，那应该就不会出现 m 和 n 都是 0 的情况。

诡异的输出结果

不过人在江湖上混，还是要严谨一点。好在这代码逻辑也不复杂，那就写一段简单的程序来验证下吧：

#include <iostream>#include <thread>
using namespace std;
int x = 0, y = 0, m = 0, n = 0;int main(){	while (1) {		x = y = 0;		thread t1([&]() { x = 1; m = y; });		thread t2([&]() { y = 1; n = x; });		t1.join(); t2.join();
		if (m == 0 && n == 0) {			cout << " m == 0 && n == 0 ? impossible!\n";		}	}	return 0;}

考虑到多线程的随机性，就写一个无限循环多跑一会吧，反正屏幕也不会有什么输出。我们信心满满的把程序跑了起来，但很快就发现有点不太对劲：

​m 和 n 居然真的同时为 0 了？不可能不可能...这难道是 windows 或者 msvc 的 bug？那我们到 linux 上用 g++编译试一下，结果程序跑起来之后，又看到了熟悉的输出：

​这...打脸未免来得也太快了吧！

C/C++Linux服务器开发高级架构师/C++后台开发架构师​免费学习地址

【文章福利】另外还整理一些 C++后台开发架构师 相关学习资料，面试题，教学视频，以及学习路线图，免费分享有需要的可以自行添加：Q群：720209036 点击加入~ 群文件共享

你看到的执行顺序不是真的执行顺序

看来这不是 bug，真的是有可能出现 m 和 n 都是 0 的情况。可是，到底是为什么呢？恍惚之间，我们突然想起曾经似乎在哪看过这样一个 as-if 规则：

The rule that allows any and all code transformations that do not change the observable behavior of the program.

也就是说，在不影响可观测结果的前提下，编译器是有可能对程序的代码进行重排，以取得更好的执行效率的。比如像这样的代码：

int a, b;void test(){	a = b + 1;	b = 1;}

编译器是完全有可能重新排列成下面的样子的：

int a, b;void test(){	int c = b;	b = 1;	c += 1;	a = c;}

这样，程序在实际执行过程中对 a 的赋值就晚于对 b 的赋值之后了。不过，有了前车之鉴，我们还是先验证一下在下结论吧。我们使用 gcc 的-S 选项，生成汇编代码(开启-O2 优化)来看一下，编译器生成的指令到底是什么样子的：

​哈哈，果然如我们所料，对 a 的赋值被调整到对 b 的赋值后面了！那上面 m 和 n 同时为 0 也一定是因为编译器重新排序我们的指令顺序导致的！想到这里，我们的底气又渐渐回来了。那就生成汇编代码看看吧：

​果然不出所料，因为我们在编译的时候开了-O3 优化，赋值的顺序被重排了！代码实际的执行顺序大概是下面这个样子：

int t1 = y; x = 1; m = t1; //线程1	int t2 = x; y = 1; n = t2; //线程2

这就难怪会出现 m = 0, n = 0 这样的结果了。分析到这里，我们终于有点松了一口气，这多年的编程经验可不是白来的，总算是给出了一个合理的解释。那我们在编译的时候把-O3 优化选项去掉，尽量让编译器不要进行优化，保持原来的指令执行顺序，应该就可以避免 m 和 n 同时为 0 的结果了吧？试试，保险起见，我们还是先看一看汇编代码吧：

​跟我们的预期一致，汇编代码保持了原来的执行顺序，这回肯定没有问题了。那就把程序跑起来吧。然而...不一会儿，熟悉的打印又出现了...

​这...到底是怎么回事？！！！

你看到的执行顺序还不是真正的执行顺序

如果不是编译器重排了我们的指令顺序，那还会是什么呢？难道是 CPU？！还真是。实际上，现代 CPU 为了提高执行效率，大多都采用了流水线技术。例如：一个执行过程可以被分为：取指(IF)，译码(ID)，执行(EX)，访存(MEM)，回写(WB)等阶段。这样，当第一条指令在执行的时候，第二条指令可以进行译码，第三条指令可以进行取指...于是 CPU 被充分利用了，指令的执行效率也大大提高。一个标准的 5 级流水线的工作过程如下表所示(实际的 CPU 流水线远比这复杂得多)：

上面展示的指令流水线是完美的，然而实际情况往往没有这么理想。考虑这样一种情况，假设第二条指令依赖于第一条指令的执行结果，而第一条指令恰巧又是一个比较耗时的操作，那么整个流水线就停止了。即使第三条指令与前两条指令完全无关，它也必须等到第一条指令执行完成，流水线继续运转时才能得已执行。这就浪费了 CPU 的执行带宽。乱序执行(Out-Of-Order Execution)就是被用来解决这一问题的，它也是现代 CPU 提升执行效率的基础技术之一。简单来说，乱序执行是指 CPU 提前分析待执行的指令，调整指令的执行顺序，以期发挥更高流水线执行效率的一种技术。引入乱序执行技术以后，CPU 执行指令过程大概是下面这个样子：

所以，上面的程序出现(m, n)结果为(0, 0)的情况，应该就是因为指令的执行顺序被 CPU 重排了！

C++多线程内存模型

我们通常将读取操作称为 load，存储操作称为 store。对应的内存操作顺序有以下几种：

1. load->load(读读)

2. load->store(读写)

3. store->load(写读)

4. store->store(写写)

CPU 在执行指令的时候，会根据情况对内存操作顺序进行重新排列。也就是说，我们只要能够让 CPU 不要进行指令重排优化，那么应该就不会出现(m, n)为(0, 0)的情况了。但具体要怎么做呢？实际上，在 C++11 之前，我们很难在语言层面做到这件事情。那时的 C++甚至连线程都不支持，更别提什么内存模型了。在 C++98 的年代，我们只能通过嵌入汇编的方式添加内存屏障来达到这样的目的：

asm volatile("mfence" ::: "memory");

不过在现代 C++中，要做这样的事情就简单多了。C++11 引入了原子类型(atomic)，同时规定了 6 种内存执行顺序：

1. memory_order_relaxed: 松散的，在保证原子性的前提下，允许进行任务的重新排序;

2. memory_order_release: 代码中这条语句前的所有读写操作, 不允许被重排到这个操作之后;

3. memory_order_acquire: 代码中这条语句后的所有读写操作，不允许被重排到这个操作之前；

4. memory_order_consume: 代码中这条语句后所有与这块内存相关的读写操作，不允许被重排到这个操作之前；注意，这个类型已不建议被使用；

5. memory_order_acq_rel: 对读取和写入施加 acquire-release 语义，无法被重排；

6. memory_order_seq_cst: 顺序一致性，如果是写入就是 release 语义，如果是读取是 acquire 语义，如果是读取-写入就是 acquire-release 语义；也是原子变量的默认语义。

所以，我们只需要将 x 和 y 的类型改为 atmioc_int，就可以避免 m 和 n 同时为 0 的结果出现了。修改后的代码如下：

#include <iostream>#include <thread>#include <atomic>
using namespace std;
atomic_int x(0);atomic_int y(0);int m = 0, n = 0;int main(){        while (1) {                x = y = 0;                thread t1([&]() { x = 1; m = y; });                thread t2([&]() { y = 1; n = x; });                t1.join(); t2.join();
                if (m == 0 && n == 0) {                        cout << " m == 0 && n == 0 ? impossible!\n";                }        }        return 0;}

现在编译运行一下，看看结果：

​已经不会再出现"impossible"的打印了。我们再来看看生成的汇编代码：

​原来编译器已经自动帮我们插入了内存屏障，这样就再也不会出现(m, n)为(0, 0)的情况了。