C 内存模型
时间：2021-10-11 14:21:40
[导读]↓推荐关注↓本文是《C并发编程》一文的姊妹篇。将着重介绍C11标准引入的内存模型。前言在《C并发编程》一文中，我们已经介绍了C11到C17在并发编程方面的新增API。借助那篇文章中的知识，你应该已经可以开发一个完善的C并发系统。这对绝大部分人来说，是足够的了。但在一些情况下，我们...
↓推荐关注↓
本文是《C 并发编程》一文的姊妹篇。将着重介绍C 11标准引入的内存模型。img img img img img
除了上面这些，还有更多关于整形类型的原子类型，详见：cppreference std::atomic[15]。“原子操作”正如其名称所示：该操作要么是执行完了，要么是没有执行，从任何一个线程中，都无法观察到中间状态。以原子读操作为例：如果有其他线程进行了原子写操作，那么原子读操作，要么获取到的是修改前的值，要么是修改后的，不会是修改了一半的值。而非原子类型就不一样了。如果尝试修改非原子类型对象，其他线程可能看到的既不是修改前的值，也不是修改后的值。关于这一点，在C 并发编程中，我们就看到了非原子类型所引起的问题。需要注意的是，所有原子类型都不支持拷贝和赋值。因为该操作涉及了两个原子对象：要先从另外一个原子对象上读取值，然后再写入另外一个原子对象。而对于两个不同的原子对象上单一操作不可能是原子的。不同的原子类型包含了不同的原子操作，下表将原子类型分为四类，并列出了它们所支持的操作（为了简洁，列名上类名中的
本文是《C 并发编程》一文的姊妹篇。将着重介绍C 11标准引入的内存模型。
前言
在《C 并发编程》一文中，我们已经介绍了C 11到C 17在并发编程方面的新增API。借助那篇文章中的知识，你应该已经可以开发一个完善的C 并发系统。这对绝大部分人来说，是足够的了。但在一些情况下，我们可能还需要走得更远。回顾一下，上文中提到的知识是以互斥体为中心的。为了避免竞争条件，是保证任何时候只有一个线程可以进入临界区。这就存在两个问题：- 可能会出现死锁
- 并发的效率不够
关于C 内存模型
2004年，Java 5.0引入了适用于多线程环境的内存模型[2]：JSR-133[3]。但C 直到2011标准才引入了内存模型。Java内存模型在很大程度上影响了C 内存模型，但后者走得更远。因为它允许开发者打破顺序一致性（Sequential Consistency，我们会在下文中讲解），以获得更好的控制。之所以这么做是因为C 是一门系统编程语言，它的设计意图之一就是：不需要另外一个更底层的语言，而是直接提供给开发者以”接近机器“的方式编程。即便大多数程序员不用在意内存模型，但是当你以“接近机器”的方式工作时，了解这些原理就很重要了。内存模型是多线程环境能够可靠工作的基础，因为内存模型需要对多线程环境的运作细节进行完备的定义。简单来讲，可以认为内存模型是一种契约。它定义一套操作手法以及这些操作手法背后的详细含义。开发者利用这套操作完成数据的同步以避免竞争条件，而系统（包括：编译器，操作系统和处理器）保证执行的逻辑符合内存模型对于相关操作的定义 – 即实现契约。内存模型主要包含了下面三个部分：- 元子操作：顾名思义，这类操作一旦执行就不会被打断，你无法看到它的中间状态，它要么是执行完成，要么没有执行。
- 操作的局部顺序：一系列的操作不能被乱序。
- 操作的可见性：定义了对于共享变量的操作如何对其他线程可见。
为什么需要内存模型？
在C 11标准出来之前，C 环境没有多线程的概念。编译器和处理器认为系统中只有一个执行流。引入了多线程之后，情况就会变得非常复杂。这是因为：现代计算机系统为了加快执行效率，自动的包含了很多的优化。这些优化虽然保证了在单线程环境下不破坏原来的逻辑。但是一旦到了多线程之后，情况就不一样了。事实上，开发者编写的代码和最终运行的程序往往会存在较大的差异，而运行结果与开发者预想一致，只是一种“假象”罢了。之所以会产生差异，原因主要来自下面三个方面：- 编译器优化
- CPU out-of-order执行
- CPU Cache不一致性
Memory Reorder
以下面这段伪代码为例：X = 0, Y = 0;
Thread 1:
X = 1; // ①
r1 = Y; // ②
Thread 2:
Y = 1;
r2 = X;
你可能会觉得，在这个程序执行完成之后，r1和r2怎么都不可能同时为0。但事实并非如此[4]。这是因为“Memory Reorder”的存在，“Memory Reorder”包含了编译器和处理器两种类型的乱序。编译器优化
以gcc为例，该编译器提供了-o参数来控制非常多的优化选项[6]。以下面这段代码为例：int A, B;
void foo()
{
A = B 1;
B = 0;
}
在编译优化后，可能会变成下面这样：int A, B;
void foo()
{
int temp = B;
B = 0;
A = temp 1;
}
请注意，编译器只要保证：在单线程环境下，执行的结果和原先一样就可以了。所以，这样做是可以的。对于编译器来说，它知道的是：当前线程中，数据的读写以及数据之间的依赖关系。但是，编译器并不知道哪些数据是在线程间共享，而且是有可能会被修改的。这就需要开发者在软件层面做好控制。对于编译器的乱序优化来说，开发者并非完全不能控制。编译器会提供称之为内存栅栏（Memory Barrier）[7]的工具给开发者，让开发者告诉编译器：这部分代码编译的时候不能乱序。gcc的内存栅栏写法如下：int A, B;
void foo()
{
A = B 1;
asm volatile("" ::: "memory");
B = 0;
}
Out-of-order执行
不仅仅是编译器，处理器也可能会乱序执行指令。下面是维基上给出的一张表格，列出了不同类型的CPU可能会执行的乱序类别。- Weak vs. Strong Memory Models[9]
- This Is Why They Call It a Weakly-Ordered CPU[10]
- A Tutorial Introduction to the ARM and POWER Relaxed Memory Models[11]
- x86-TSO: A Rigorous and Usable Programmer’s Model for x86 Multiprocessors[12]
fence指令：lfence (asm), void _mm_lfence(void)
sfence (asm), void _mm_sfence(void)
mfence (asm), void _mm_mfence(void)
由此提醒我们：如果我们只以单线程的思维来开发并发系统，一旦引入了Memory Reorder之后就可能会发生问题。例如：以上面的A，B两个变量为例，在编译器将其乱序后，虽然对于当前线程是没问题的。但是如果在此时刚好有另外一个线程使用这两个变量，并且依赖于它们的更新顺序，那么就会出现问题。Cache Coherency
事情还不只这么简单。现代的主流CPU几乎都会包含多个核以及多级Cache，下图是我的MacBook Pro上的CPU Cache信息。对象和内存位置
C 内存模型中的基本存储单位是字节。一个字节至少足够大，能够包含基本执行字符集的任何成员以及Unicode UTF-8编码形式的八位代码单元，并且由连续的位序列组成。C 中所有数据都是由对象组成的。这里的对象包括了简单基本类型（如int和double），也包括了指针类型（如my_class*）。当然，也包括各种class定义的类的对象。无论是什么类型，一个对象均包含了一个或多个内存位置。每个内存位置一定是下面两种情况中的一种：- 标量类型（Scalar Type）的对象，标量类型包括下面几种：
- 数字类型：整数或者浮点数
T *指针类型- 枚举类型
- 指向成员的指针
nullptr_t- 相邻位域（Bit field）[13]的最大序列
位域
位域声明具有以“位”为单位的明确大小的类数据成员。相邻的位域成员可以打包成共享和跨过各个字节。例如这样：struct S {
// 三位的无符号位域，
// 允许值为 0...7
unsigned int b : 3;
};
位域的值必须大于等于0。值0比较特殊，它仅允许使用在无名位域上。并且它具有特殊含义：它指定类定义中的下个位域将始于分配单元的边界。由此，请看一下下面的例子：struct S {
char a; // 内存位置 #1
int b : 5; // 内存位置 #2
int c : 11, // 内存位置 #2 （接续，相邻位域占用同一个内存位置）
: 0, // 无名位域，分隔了下一个位域
d : 8; // 内存位置 #3 （由于存在0值无名位域，这里是一个新的内存位置）
struct {
int ee : 8; // 内存位置 #4
} e;
} obj;
可以看到，这个结构包含了4个内存位置。之所以介绍内存位置，是因为这与内存模型密切相关。如果多个线程各自访问的是不同的内存位置，那么就不会有什么问题。但是，如果它们同时访问了相同的内存位置，那就要小心了。**当多个线程访问同一个内存位置，并且其中只要有一个线程包含了写操作，如果这些访问没有一致的修改顺序，那么结果就是未定义的。**也就是说：可能会发生bug。修改顺序
我们已经知道，C 中的数据都是由对象组成。一个对象包含了若干个内存位置。每个对象从初始化开始，直到最终销毁，在其生命周期的范围内，对它进行的访问必须有一个确定的修改顺序，这个顺序包含了所有线程的访问操作。虽然程序的每一次运行，这个顺序可能是不一样的（例如：CPU资源的变化，调度器的影响），但是针对其中具体的某一次来说，必须有一个“一致的顺序”，这个顺序要被所有的线程认可，并且可见。例如：一旦某个线程修改了一个数据，这个操作必须要让所有线程知道，在修改操作之后，所有线程都应该得到修改后的值。从数据类型的角度来说，有两种情况：- 对于原子类型（见下文）：由编译器保证数据的同步。
- 对于非原子类型：由开发者保证。
关系术语
下面先来介绍C 内存模型中的几个关系术语。sequenced-before
sequenced-before是一种单线程上的关系，这是一个非对称，可传递的成对关系。对于两个操作A和B，如果A sequenced-before B，则A的执行应当在B的前面，并且A执行后的结果B也能看到，它引入了一个局部有序性。同一个线程中的多个语句之间就是sequenced-before关系，例如：int i = 7; // ①
i ; // ②
这里的 ① sequenced-before ② 。但是同一个语句中的多个子表达式上没有这个关系的。特别极端的，对于下面这个语句：i = i i;
由于等号右边的两个子表达式无法确定先后关系，因此这个语句的行为是未定义的。这意味着，你永远不应该写这样的代码。happens-before
happens-before关系是sequenced-before关系的扩展，因为它还包含了不同线程之间的关系。如果A happens-before B，则A的内存状态将在B操作执行之前就可见，这就为线程间的数据访问提供了保证。同样的，这是一个非对称，可传递的关系。如果A happens-before B，B happens-before C。则可推导出A happens-before C。synchronizes-with
synchronizes-with描述的是一种状态传播（propagate）关系。如果A synchronizes-with B，则就是保证操作A的状态在操作B执行之前是可见的。下文中我们将看到，原子操作的acquire-release具有synchronized-with关系。除此之外，对于锁和互斥体的释放和获取可以达成synchronized-with关系，还有线程执行完成和join操作也能达成synchronized-with关系。最后，借助 synchronizes-with 可以达成 happens-before 关系。原子类型与原子操作
要理解内存模型，首先需要掌握C 11提供的原子类型（atomic types）和原子操作（atomic operation）。原子类型不是一个类，而是一系列类，它们都位于关于volatile和原子类型：Java和C 都有volatile关键字。但同样的关键字在不同的语言中有着不同的含义。Java中的volatile和C 的原子类型是类似的含义。而C 中的volatile是禁止编译器对这个变量进行优化。
| 类型别名 | 类型定义 |
|---|---|
| atomic_bool | std::atomic |
| atomic_char | std::atomic |
| atomic_schar | std::atomic |
| atomic_uchar | std::atomic |
| atomic_int | std::atomic |
| atomic_uint | std::atomic |
| atomic_short | std::atomic |
| atomic_ushort | std::atomic |
| atomic_long | std::atomic |
| atomic_ulong | std::atomic |
| atomic_llong | std::atomic |
| atomic_ullong | std::atomic |
| atomic_char16_t | std::atomic |
| atomic_char32_t | std::atomic |
| atomic_wchar_t | std::atomic |
atomic用#代替）。| 函数 | #_flag | #_bool | 指针类型 | 整形类型 | 说明 |
|---|---|---|---|---|---|
| test_and_set | Y | 将flag设为true并返回原先的值 | |||
| clear | Y | 将flag设为false | |||
| is_lock_free | Y | Y | Y | 检查原子变量是否免锁 | |
| load | Y | Y | Y | 返回原子变量的值 | |
| store | Y | Y | Y | 通过一个非原子变量的值设置原子变量的值 | |
| exchange | Y | Y | Y | 用新的值替换，并返回原先的值 | |
| compare_exchange_weak compare_exchange_strong | Y | Y | Y | 比较和改变值 | |
| fetch_add, = | Y | Y | 增加值 | ||
| fetch_sub, -= | Y | Y | 减少值 | ||
| , -- | Y | Y | 自增和自减 | ||
| fetch_or, |= | Y | 求或并赋值 | |||
| fetch_and,
本站声明： 本文章由作者或相关机构授权发布，目的在于传递更多信息，并不代表本站赞同其观点，本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者，如若文章内容侵犯您的权益，请及时联系本站删除（ 邮箱：macysun@21ic.com ）。
换一批
延伸阅读
|
下载文档
