题记:看代码不要死死的一条一条往后看,要适当的联系上下文,看出整体逻辑性,流程性。事实上,编译器和处理器也不是呆板的一条一条往后执行的,它也会有预取和逻辑判断。
由内存屏障到RCU的发布订阅
内存屏障主要解决的问题是编译器的优化和CPU的乱序执行。
编译器在优化的时候,生成的汇编指令可能和c语言程序的执行顺序不一样,在需要程序严格按照c语言顺序执行时,需要显式的告诉编译不需要优化,这在linux下是通过barrier()宏完成的,它依靠volidate关键字和memory关键字,前者告诉编译barrier()周围的指令不要被优化,后者作用是告诉编译器汇编代码会使内存里面的值更改,编译器应使用内存里的新值而非寄存器里保存的老值。
同样,CPU执行会通过乱序以提高性能。汇编里的指令不一定是按照我们看到的顺序执行的。linux中通过mb()系列宏来保证执行的顺序。简单的说,如果在程序某处插入了mb()/rmb()/wmb()宏,则宏之前的程序保证比宏之后的程序先执行,从而实现串行化。
即使是编译器生成的汇编码有序,处理器也不一定能保证有序。就算编译器生成了有序的汇编码,到了处理器那里也拿不准是不是会按照代码顺序执行。所以就算编译器保证有序了,程序员也还是要往代码里面加内存屏障才能保证绝对访存有序,这倒不如编译器干脆不管算了,因为内存屏障本身就是一个sequence point,加入后已经能够保证编译器也有序。
处理器虽然乱序执行,但最终会得出正确的结果,所以逻辑上讲程序员本不需要关心处理器乱序的问题。但是在SMP并发执行的情况下,处理器无法知道并发程序之间的逻辑,比如,在不同core上的读者和写者之间的逻辑。简单讲,处理器只保证在单个core上按照code中的顺序给出最终结果。这就要求程序员通过mb()/rmb()/wmb()/read_barrier_depends来告知处理器,从而得到正确的并发结果。内存屏障、数据依赖屏障都是为了处理SMP环境下的数据同步问题,UP根本不存在这个问题。
下面分析下内存屏障在RCU上的应用:
#define rcu_assign_pointer(p,v) ({ \
smp_wmb();\
(p)= (v); \
})
#define rcu_dereference(p) ({ \
typeof(p)_________p1 =ACCESS_ONCE(p); \
smp_read_barrier_depends();\
(_________p1);\
})
rcu_assign_pointer()通常用于写者的发布,rcu_dereference()通常用于读者的订阅。
写者:
1 p->a = 1;
2 p->b = 2;
3 p->c = 3;
4 rcu_assign_pointer(gp, p);
读者:
1 rcu_read_lock();
2 p = rcu_dereference(gp);
3 if (p != NULL) {
4 do_something_with(p->a, p->b, p->c);
5 }
6 rcu_read_unlock();
rcu_assign_pointer()是说,先把那块内存写好,再把指针指过去。这里使用的内存写屏障是为了保证并发的读者读到数据一致性。在这条语句之前的读者读到旧的指针和旧的内存,这条语句之后的读者读到新的指针和新的内存。如果没有这条语句,很有可能出现读者读到新的指针和旧的内存。也就是说,这里通过内存屏障刷新了p所指向的内存的值,至于gp本身的值有没有更新还不确定。实际上,gp本身值的真正更新要等到并发的读者来促发。
rcu_dereference()原语用的是数据依赖屏障,smp_read_barrier_dependence,它要求后面的读操作如果依赖前面的读操作,则前面的读操作需要首先完成。根据数据之间的依赖,要读p->a, p->b, p->c,就必须先读p,要先读p,就必须先读p1,要先读p1,就必须先读gp。也就是说读者所在的core在进行后续的操作之前,gp必须是同步过的当前时刻的最新值。如果没有这个数据依赖屏障,有可能读者所在的core很长一段时间内一直用的是旧的gp值。所以,这里使用数据依赖屏障是为了督促写者将gp值准备好,是为了呼应写者,这个呼应的诉求是通过数据之间的依赖关系来促发的,也就是说到了非呼应不可的地步了。
下面看看kernel中常用的链表操作是如何使用这样的发布、订阅机制的:
写者:
static inline void list_add_rcu(struct list_head *new,struct list_head *head)
{
__list_add_rcu(new, head, head->next);
}
static inline void __list_add_rcu(struct list_head * new,
struct list_head * prev, struct list_head * next)
{
new->next = next;
new->prev = prev;
smp_wmb();
next->prev = new;
prev->next = new;
}
读者:
#define list_for_each_entry_rcu(pos, head, member) \
for(pos = list_entry((head)->next, typeof(*pos), member); \
prefetch(rcu_dereference(pos)->member.next),\
&pos->member!= (head); \
pos= list_entry(pos->member.next, typeof(*pos), member))
写者通过调用list_add_rcu来发布新的节点,其实是发布next->prev, prev->next这两个指针。读者通过list_for_each_entry_rcu来订阅这连个指针,我们将list_for_each_entry_rcu订阅部分简化如下:
pos = prev->next;
prefetch(rcu_dereference(pos)->next);
读者通过rcu_dereference订阅的是pos,而由于数据依赖关系,又间接订阅了prev->next指针,或者说是促发prev->next的更新。
由RCU引出的ACCESS_ONCE宏
定义
它的定义很简单,在 include/linux/compiler.h的底部:
C:
1. #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
仅从语法上讲,这似乎毫无意义,先取其地址,在通过指针取其值。而实际上不然,多了一个关键词 volatile,所以它的含义就是强制编译器每次使用 x都从内存中获取。
原因
仅仅从定义来看基本上看不大出来为什么要引入这么一个东西。可以通过几个例子(均来自Paul,我做了小的修改)看一下。
1. 循环中有每次都要读取的全局变量:
C:
1. ...
2. static int should_continue;
3. static void do_something(void);
4. ...
5. while (should_continue)
6. do_something();
假设 do_something()函数中并没有对变量 should_continue做任何修改,那么,编译器完全有可能把它优化成:
C:
1. ...
2. if (should_continue)
3. for (;;)
4. do_something();
这很好理解,不是吗?对于单线程的程序,这么做完全没问题,可是对于多线程,问题就出来了:如果这个线程在执行do_something()的期间,另外一个线程改变了 should_continue的值,那么上面的优化就是完全错误的了!更严重的问题是,编译器根本就没有办法知道这段代码是不是并发的,也就无从决定进行的优化是不是正确的!
这里有两种解决办法:1)给 should_continue加锁,毕竟多个进程访问和修改全局变量需要锁是很自然的;2)禁止编译器做此优化。加锁的方法有些过了,毕竟 should_continue只是一个布尔,而且退一步讲,就算每次读到的值不是最新的 should_continue的值也可能是无所谓的,大不了多循环几次,所以禁止编译器做优化是一个更简单也更容易的解决办法。我们使用 ACCESS_ONCE()来访问 should_continue:
C:
1. ...
2. while (ACCESS_ONCE(should_continue))
3. do_something();
2. 指针读取一次,但要dereference多次:
C:
1. ...
2. p = global_ptr;
3. if (p && p->s && p->s->func)
4. p->s->func();
那么编译器也有可能把它编译成:
C:
1. ...
2. if (global_ptr && global_ptr->s && global_ptr->s->func)
3. global_ptr->s->func();
你可以谴责编译器有些笨了,但事实上这是C标准允许的。这种情况下,另外的进程做了 global_ptr = NULL;就会导致后一段代码 segfault,而前一段代码没问题。同上,所以这时候也要用 ACCESS_ONCE():
C:
1. ...
2. p = ACCESS_ONCE(global_ptr);
3. if (p && p->s && p->s->func)
4. p->s->func();
3. watchdog中的变量:
C:
1. for (;;) {
2. still_working = 1;
3. do_something();
4. }
假设 do_something()定义是可见的,而且没有修改 still_working的值,那么,编译器可能会把它优化成:
C:
1. still_working = 1;
2. for (;;) {
3. do_something();
4. }
如果其它进程同时执行了:
C:
1. for (;;) {
2. still_working = 0;
3. sleep(10);
4. if (!still_working)
5. panic();
6. }
通过 still_working变量来检测 wathcdog是否停止了,并且等待10秒后,它确实停止了,panic()!经过编译器优化后,就算它没有停止也会 panic!!所以也应该加上 ACCESS_ONCE():
C:
1. for (;;) {
2. ACCESS_ONCE(still_working) = 1;
3. do_something();
4. }
综上,我们不难看出,需要使用 ACCESS_ONCE()的两个条件是:
1. 在无锁的情况下访问全局变量;
2. 对该变量的访问可能被编译器优化成合并成一次(上面第1、3个例子)或者拆分成多次(上面第2个例子)。
例子
Linus 在邮件中给出的另外一个例子是:
编译器有可能把下面的代码:
C:
1. if (a> MEMORY) {
2. do1;
3. do2;
4. do3;
5. } else {
6. do2;
7. }
优化成:
C:
1. if (a> MEMORY)
2. do1;
3. do2;
4. if (a> MEMORY)
5. do3;
这里完全符合上面我总结出来的两个条件,所以也应该使用 ACCESS_ONCE()。正如 Linus 所说,不是编译器一定会这么优化,而是你无法证明它不会做这样的优化。