编译器屏障概述

文章目录

  • [1. 前言](#1. 前言)
  • [2. 编译器内存屏障](#2. 编译器内存屏障)
    • [2.1 编译器内存访问重排序规则](#2.1 编译器内存访问重排序规则)
    • [2.2 编译器屏障的几种形式](#2.2 编译器屏障的几种形式)
      • [2.2.1 显式编译器屏障](#2.2.1 显式编译器屏障)
      • [2.2.2 隐式编译器屏障](#2.2.2 隐式编译器屏障)
      • [2.2.3 硬件内存屏障充当编译屏障](#2.2.3 硬件内存屏障充当编译屏障)
      • [2.2.4 编程语言内存模型提供的编译屏障](#2.2.4 编程语言内存模型提供的编译屏障)
    • [2.3 编译器内存屏障实例](#2.3 编译器内存屏障实例)
      • [2.3.1 Linux spinlock](#2.3.1 Linux spinlock)
  • [3. 结语](#3. 结语)
  • [4. 参考资料](#4. 参考资料)

1. 前言

2. 编译器内存屏障

编译屏障,相对于运行时硬件屏障,它是一种编译时行为,其目的是阻止编译器对内存访问实行程序员不期望的优化行为,如存储访问合并、将循环内的读取行为移动到循环外等等。

2.1 编译器内存访问重排序规则

虽然编译器可以优化代码的存储访问,以得到更好的性能,但编译器开发人员CPU 供应商普遍应遵循的内存访问重排序的一个基本规则,该规则可以表述为:不得修改单线程程序的行为。这条基本规则的意思是,不管是编译时编译器内存访问重排序,还是运行时CPU 内存访问重排序,都要在不改变单线程行为的前提下进行。如有以下代码:

c 复制代码
int x, y;

void foo(void)
{
    x = y + 1;
    y = 0;
}

假定代码通过如下版本 ARM GCC 编译器(这也是本文所有示范代码采用的编译器)进行编译:

bash 复制代码
$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

不启用优化的情形下编译,会生成如下汇编代码(只截取函数 foo() 对应部分):

c 复制代码
$ arm-linux-gnueabi-gcc -S foo.c
c 复制代码
/* foo.s */

...
	.type	foo, %function
foo:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 1, uses_anonymous_args = 0
	@ link register save eliminated.
	str	fp, [sp, #-4]!
	add	fp, sp, #0
	ldr	r3, .L2 // r3 = &y
	ldr	r3, [r3] // r3 = y
	add	r3, r3, #1 // r3 = y + 1
	ldr	r2, .L2+4 // r2 = &x
	str	r3, [r2] // (1) x = y + 1
	ldr	r3, .L2 // r3 = &y
	mov	r2, #0 // r2 = 0
	str	r2, [r3] // (2) y = 0
	nop
	sub	sp, fp, #0
	@ sp needed
	ldr	fp, [sp], #4
	bx	lr
.L3:
	.align	2
.L2:
	.word	y
	.word	x
...

从上面编译器生成的汇编代码代码我们看到,在上面 (1)(2) 处,先 x = y + 1;y = 0; 是符合编程顺序的。再看一下,在(加上 -O2 编译选项)启用编译器优化的情形下,会生成怎样的汇编代码(只截取函数 foo() 对应部分):

bash 复制代码
$ arm-linux-gnueabi-gcc -O2 -S foo.c
bash 复制代码
/* foo.s */

...
	.type	foo, %function
foo:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	mov	r0, #0
	ldr	r2, .L2 // r2 = &y
	ldr	r1, .L2+4 // r1 = &x
	ldr	r3, [r2] // r3 = y
	str	r0, [r2] // (1) x = 0 
	add	r3, r3, #1 // r3 = y + 1
	str	r3, [r1] // (2) x = y + 1
	bx	lr
.L3:
	.align	2
.L2:
	.word	y
	.word	x
...

我们看到,优化后的汇编代码,在 (1)(2) 处,将 x = 0; 的赋值操作,放在了 x = y + 1 的赋值操作之前,这前面的编程顺序不一致,也即编译器出现了对存储访问的重排序。由于 y 的初始值为0,所以 x = 0;x = y + 1 无论哪个在前执行,在单线程执行环境下,都不影响结果,这遵循前面提到的规则。

由于这条规则,编写单线程代码的程序员基本上不会注意到内存重排序。在多线程编程中,它也经常被忽视,因为互斥锁信号量自带编译屏障功能,可以防止在它们周围的内存操作重排序。只有当使用无锁技术时,当内存在线程之间共享而没有任何互斥操作时,可以清楚地观察到内存重排序的效果。编译器的内存访问重排序通常只在启用优化的时候发生。在单处理器系统上,编译屏障已经足够保障对数据的并发访问安全,因为不会出现真正的并行访问,毕竟系统中只有一个处理器。

2.2 编译器屏障的几种形式

2.2.1 显式编译器屏障

以 GCC 编译器为例,来说明显式编译器屏障,其定义如下:

c 复制代码
__asm__ volatile("" ::: "memory")

"memory" 阻止将变量缓存到寄存器,强制从内存读取;同时如果访问变量既没有出现在 __asm__ 语句的 input 部分,也没有出现在 __asm__ 语句的 output 部分,则还要加上 __volatile__ 关键字,强制从内存读取。__volatile__ 关键字同时也阻止了编译移动语句(譬如移出循环),指令重排。
编译器(显式)屏障的作用,就是阻止对其前后的内存访问进行重排序。还是以章节 2.1 的代码为例,在其中插入插入一个显式编译器屏障,仍然用 -O2 优化选项进行编译,看是否能阻止对 x = y + 1; 和 y = 0; 的重排序。修改后的代码如下:

c 复制代码
int x, y;

void foo(void)
{
    x = y + 1;
	asm volatile("" ::: "memory"); // 插入一个编译屏障
    y = 0;
}

再看一下,在(加上 -O2 编译选项)启用编译器优化的情形下,会生成怎样的汇编代码(只截取函数 foo() 对应部分):

c 复制代码
$ arm-linux-gnueabi-gcc -O2 -S foo.c
c 复制代码
...
	.type	foo, %function
foo:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	@ A = B + 1;
	ldr	r2, .L2 // r2 = &y
	ldr	r1, .L2+4 // r1 = &x
	ldr	r3, [r2] // r3 = y
	add	r3, r3, #1 // r3 = y + 1
	str	r3, [r1] // (1) x = y + 1
	mov	r3, #0 // r3 = 0
	str	r3, [r2] // (2) y = 0
	bx	lr
.L3:
	.align	2
.L2:
	.word	y
	.word	x
...

我们看到,在加入(显式)编译器屏障后,优化后的汇编代码,在 (1)(2) 处,已经按编程顺序执行了对 xy 的存储访问,这是编译屏障起了作用。

2.2.2 隐式编译器屏障

在代码里面的一些 sequence points 如函数调用、对 volatile 变量的访问等,可以作为隐式编译屏障。事实上,大多数函数调用都可充当编译器屏障,无论它们自身是否包含编译器屏障,但这不包括内联函数、使用 pure 属性声明的函数以及使用链接时生成的代码。另外,带编译屏障的函数,哪怕内联了,也作为编译屏障使用。下面来看函数做为隐式编译器屏障的一个例子:

c 复制代码
int x, y;

void foo(void)
{
    x = y + 1;
    y = 0;
}

struct foo_data {
	int bar, bar2;
};

void do_something(struct foo_data *foo_data)
{
	foo_data->bar = 5;
	foo();
	foo_data->bar2 = foo_data->bar;
}

开启 -O2 选项进行编译:

bash 复制代码
$ arm-linux-gnueabi-gcc -O2 -S foo.c

生成如下汇编代码(只截取相关部分):

c 复制代码
...
	.type	do_something, %function
do_something:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	str	lr, [sp, #-4]! // 保存 lr 到堆栈
	mov	r1, #5 // r1 = 5
	mov	lr, #0 // lr = 0
	ldr	r2, .L6 // r2 = &y
	ldr	ip, .L6+4 // ip = &x
	ldr	r3, [r2] // r3 = y
	str	r1, [r0, #4] // (1) foo_data->bar2 = 5
	add	r3, r3, #1 // r3 = y + 1
	str	r1, [r0] // foo_data->bar = 5 (2)
	str	lr, [r2] // y = 0
	str	r3, [ip] // x = y + 1
	ldr	pc, [sp], #4 // 从 do_something() 函数返回
.L7:
	.align	2
.L6:
	.word	y
	.word	x
...

从汇编代码看到,函数 foo() 已经被内联到函数 do_something() 内,且 在 (1)(2) 处,foo_data->bar = 5;foo_data->bar2 = foo_data->bar; 的顺序和编程顺序正好相反,即产生了编译乱序。为避免这种情况,第 1 种方法是阻止函数 foo() 被内联,第 2 种方法是在函数 foo() 内插入编译屏障。这里只演示第 1 种方法,修改后代码如下:

c 复制代码
int x, y;

void foo(void) __attribute__((noinline)); // 阻止函数 foo() 被内联

void foo(void)
{
    x = y + 1;
    y = 0;
}

struct foo_data {
	int bar, bar2;
};

void do_something(struct foo_data *foo_data)
{
	foo_data->bar = 5;
	foo();
	foo_data->bar2 = foo_data->bar;
}

开启 -O2 选项进行编译:

bash 复制代码
$ arm-linux-gnueabi-gcc -O2 -S foo.c

生成如下汇编代码(只截取相关部分):

c 复制代码
	.type	do_something, %function
do_something:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	mov	r3, #5 // r3 = 5
	push	{r4, lr} // 保存 r4, lr 到堆栈
	mov	r4, r0 // r4 = foo_data
	str	r3, [r0] // (1) foo_data->bar = 5;
	bl	foo // 调用函数 foo(),函数没有被内联了
	ldr	r3, [r4] // (2) r3 = foo_data->bar
	str	r3, [r4, #4] // (3) foo_data->bar2 = foo_data->bar;
	pop	{r4, pc} // 从堆栈恢复 r4,并从函数返回

(1)(3) 处看到,编译器优化后的代码,仍然保持对 foo_data->barfoo_data->bar2 写操作顺序和代码一致,另外,从 (2) 处看到,对 foo_data->bar2 的赋值前,重新读取了 foo_data->bar 的值,这是合理的,因为我们无法知道,函数 foo() 是否对 foo_data->bar 进行了修改(譬如函数参数 foo_data 指向一个全局变量,而刚好 foo() 修改了它)

除了这些情况之外,对外部函数的调用甚至比编译器障碍更强,因为编译器不知道函数的副作用是什么。编译器必须忘记它对内存所做的任何假设,这些假设可能对该函数可见。仔细想想,这很有道理。在上面的代码片段中,假设 foo() 实现存在于外部库中,编译器如何知道 foo() 不依赖于 foo_data->bar 的值?它如何知道 foo() 不会修改内存中的 foo_data->bar?显然编译器不得而知。因此,为了遵守内存访问重排序的基本规则,它不得围绕对 foo() 这个外部调用对任何内存访问进行重排序。同样,在调用完成后,它必须从内存中加载 foo_data->bar 的新值,而不是假设它仍然等于 5,即使启用了优化。

在许多情况下,编译器指令重新排序是被禁止的,甚至当编译器必须从内存中重新加载某些值时也是如此。这些隐藏的规则构成了人们长期以来一直说 C 中的 valotile 数据类型,在正确编写的多线程代码中通常不是必需的重要原因。

2.2.3 硬件内存屏障充当编译屏障

硬件内存屏障,也可以充当编译屏障。而在单处理器系统上,所有的硬件内存屏障定义都退化为编译屏障。如 Linux 的内存屏障接口单处理器系统上定义如下:

c 复制代码
/* include/asm-generic/barrier.h */

/*
 * Force strict CPU ordering. And yes, this is required on UP too when we're
 * talking to devices.
 *
 * Fall back to compiler barriers if nothing better is provided.
 */

#ifndef mb
#define mb()	barrier()
#endif

#ifndef rmb
#define rmb()	mb()
#endif

#ifndef wmb
#define wmb()	mb()
#endif

...

#ifdef CONFIG_SMP

/* 多处理器系统定义 */

#else

/* 单处理器系统定义 */

#ifndef smp_mb
#define smp_mb()	barrier()
#endif

#ifndef smp_rmb
#define smp_rmb()	barrier()
#endif

#ifndef smp_wmb
#define smp_wmb()	barrier()
#endif

#endif	/* CONFIG_SMP */

2.2.4 编程语言内存模型提供的编译屏障

譬如 C++,引入了自己的内存模式,并提供内存屏障接口对存储访问保序。如下面的例子:

c 复制代码
int value;
std::atomic<int> is_updated(0);

void update_value(int x)
{
    value = x;
    // 在这里阻止 value 和 is_updated 存储操作的重排序
    is_updated.store(1, std::memory_order_release);
}

2.3 编译器内存屏障实例

2.3.1 Linux spinlock

c 复制代码
/* kernel/locking/qspinlock.c */

/*
 * Per-CPU queue node structures; we can never have more than 4 nested
 * contexts: task, softirq, hardirq, nmi.
 *
 * Exactly fits one 64-byte cacheline on a 64-bit architecture.
 *
 * PV doubles the storage and uses the second cacheline for PV state.
 */
/* per-cpu 的数组 mcs_nodes[MAX_NODES] */
static DEFINE_PER_CPU_ALIGNED(struct mcs_spinlock, mcs_nodes[MAX_NODES]);

void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
{
	...
queue:
	node = this_cpu_ptr(&mcs_nodes[0]); // node 指向当前 CPU 的 mcs_nodes[MAX_NODES] 数组
	idx = node->count++; // count 最大值为 MAX_NODES
	tail = encode_tail(smp_processor_id(), idx);

	node += idx; // 使用当前 CPU mcs_nodes[MAX_NODES] 的 mcs_nodes[idx]

	/*
	 * Ensure that we increment the head node->count before initialising
	 * the actual node. If the compiler is kind enough to reorder these
	 * stores, then an IRQ could overwrite our assignments.
	 */
	barrier();

	node->locked = 0;
	node->next = NULL;
	pv_init_node(node); // (1) 修改 node 指向的结构体成员变量值
	...
}

在这里,由于变量 mcs_nodes[MAX_NODES]per-cpu 的,每个 CPU 只会访问自己的变量空间,所以不用考虑多个 CPU 并行、并发访问 mcs_nodes[MAX_NODES] 的情形。在当前上下文,由于 spin_lock() 已经禁用了当前 CPU 上抢占,唯一的并发场景是在中断中也使用同一 spinlock 的情形,所以这里只要保障 node->count++ 操作在对 node 的初始化操作 node->locked = 0; node->next = NULL; pv_init_node(node); 之前完成,那么就不会出现中断中对当前 CPU 数据 mcs_nodes[idx] 的覆写,因为 mcs_nodes[MAX_NODES] 是每 CPU 的数据,所以不会有多个 CPU 对它的并行访问,对它的访问相当于单核场景。所以这里要做的,就是简单的插入一个编译屏障 barrier() 就可以了。如果读者难以能理解这里的场景,那么可以反过来思考:如果对 node 的初始化操作 node->locked = 0;node->next = NULL; pv_init_node(node); 先于 node->count++ 发生,会变成怎样?譬如某个线程刚好执行完了 pv_init_node(node); 修改了 node 的值,在 node->count++ 执行前,中断进来了,也使用和线程相同的 spinlock,然后因为线程中 node->count++ 还没执行,所以中断和线程使用同一个 node,然后修改 node 的值,这时候前面线程对 node 的修改值就会被中断中的写操作覆写。如果 保证 node->count++ 执行在前,那么线程和中断修改的将会是不同的 node ,也就不会出现覆写的情况。

3. 结语

虽然编译乱序为我们带来了很多烦恼,但它只影响无锁编程的场合,因为带锁的场合,锁自身就含有内存屏障语义

在多 CPU 系统下,编译器屏障无法阻止 CPU 带来的存储乱序,这需要硬件内存屏障来保护。

如果我们不是编译器的开发者,或者对使用的编译的各个细节非常熟悉,这时候编译器生成的汇编代码可以指导我们应该怎样、或这哪里插入编译屏障。

4. 参考资料

[1] How can I judge where should I put memory barrier in the code?

[2] GCC-Inline-Assembly-HOWTO

[3] Memory Ordering at Compile Time

[4] Optimization of conditional access to globals: thread-unsafe?

[5] https://www.oracle.com/technetwork/server-storage/solarisstudio/documentation/oss-compiler-barriers-176055.pdf

[6] https://topic.alibabacloud.com/a/understanding-memories-barrier-memory-barrier_8_8_10252214.html

[7] https://yarchive.net/comp/linux/ACCESS_ONCE.html

[8] https://yarchive.net/comp/linux/memory_barriers.html

[9] https://www.quora.com/Can-you-explain-what-a-compiler-barrier-is

[10] https://alibaba-cloud.medium.com/memory-model-and-synchronization-primitive-part-1-memory-barrier-9585e50b4735

[11] https://android.googlesource.com/kernel/msm/+/android-msm-marlin-3.18-nougat-dr1/Documentation/memory-barriers.txt

[12] https://hackmd.io/@VIRqdo35SvekIiH4p76B7g/Hy9JyrBw?type=view

[13] https://developer.arm.com/documentation/den0024/a/Memory-Ordering/Barriers/Use-of-barriers-in-C-code