文章目录
1. 前言
限于作者能力水平,本文可能存在谬误,因此而给读者带来的损失,作者不做任何承诺。
2. 编译器内存屏障
编译屏障
,相对于运行时
的硬件屏障
,它是一种编译时行为
,其目的是阻止编译器对内存访问实行程序员不期望的优化行为
,如存储访问合并、将循环内的读取行为移动到循环外等等。
2.1 编译器内存访问重排序规则
虽然编译器可以优化代码的存储访问,以得到更好的性能,但编译器开发人员
和CPU 供应商
普遍应遵循的内存访问重排序
的一个基本规则,该规则可以表述为:不得修改单线程程序的行为
。这条基本规则的意思是,不管是编译时
的编译器内存访问重排序
,还是运行时
的 CPU 内存访问重排序
,都要在不改变单线程行为的前提下
进行。如有以下代码:
int x, y;
void foo(void)
{
x = y + 1;
y = 0;
}
假定代码通过如下版本 ARM GCC
编译器(这也是本文所有示范代码采用的编译器)进行编译:
$ 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()
对应部分):
$ arm-linux-gnueabi-gcc -S foo.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()
对应部分):
$ arm-linux-gnueabi-gcc -O2 -S foo.c
/* 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 编译器为例,来说明显式编译器屏障,其定义如下:
__asm__ __volatile__("": : :"memory")
"memory"
阻止将变量缓存到寄存器,强制从内存读取;同时如果访问变量既没有出现在 __asm__
语句的 input
部分,也没有出现在 __asm__
语句的 output
部分,则还要加上 __volatile__
关键字,强制从内存读取。__volatile__
关键字同时也阻止了编译移动语句(譬如移出循环),指令重排。
编译器(显式)屏障
的作用,就是阻止对其前后的内存访问进行重排序。还是以章节 2.1
的代码为例,在其中插入插入一个显式编译器屏障,仍然用 -O2
优化选项进行编译,看是否能阻止对 x = y + 1
; 和 y = 0;
的重排序。修改后的代码如下:
int x, y;
void foo(void)
{
x = y + 1;
asm volatile("" ::: "memory"); // 插入一个编译屏障
y = 0;
}
再看一下,在(加上 -O2
编译选项)启用编译器优化
的情形下,会生成怎样的汇编代码(只截取函数 foo()
对应部分):
$ arm-linux-gnueabi-gcc -O2 -S foo.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)
处,已经按编程顺序执行了对 x
和 y
的存储访问,这是编译屏障起了作用。
2.2.2 隐式编译器屏障
在代码里面的一些 sequence points
如函数调用、对 volatile
变量的访问等,可以作为隐式编译屏障
。事实上,大多数函数调用
都可充当编译器屏障,无论它们自身是否包含编译器屏障,但这不包括
内联函数、使用 pure
属性声明的函数以及使用链接时生成的代码。另外,带编译屏障的函数,哪怕内联了,也作为编译屏障使用
。下面来看函数做为隐式编译器屏障的一个例子:
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
选项进行编译:
$ arm-linux-gnueabi-gcc -O2 -S foo.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 种方法,修改后代码如下:
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
选项进行编译:
$ arm-linux-gnueabi-gcc -O2 -S foo.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->bar
和 foo_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 的内存屏障接口
在单处理器
系统上定义如下:
/* include/linux/compiler-gcc.h */
#define barrier() __asm__ __volatile__("": : :"memory")
/* 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++,引入了自己的内存模式,并提供内存屏障接口对存储访问保序。如下面的例子:
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
/* include/linux/compiler-gcc.h */
#define barrier() __asm__ __volatile__("": : :"memory")
/* 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