
RCU的设计思想比较明确,通过新老指针替换的方式来实现免锁方式的共享保护。但是具体到代码的层面,理解起来多少还是会有些困难。下面我准备了关于Linux内核中的RCU机制的文章,提供给大家参考!
RCU读取侧进入临界区的标志是调用rcu_read_lock,这个函数的代码是:
static inline void rcu_read_lock(void)
{
__rcu_read_lock()
__acquire(RCU)
rcu_read_acquire()
}
该实现里面貌似有三个函数调用,但实质性的工作由第一个函数__rcu_read_lock()来完成,__rcu_read_lock()通过调用 preempt_disable()关闭内核可抢占性。但是中断是允许的,假设读取者正处于rcu临界区中且刚读取了一个共享数据区的指针p(但是还没有访问p中的数据成员),发生了一个中断,而该中断处理例程ISR恰好需要修改p所指向的数据区,按照RCU的设计原则,ISR会新分配一个同样大小的数据区new_p,再把老数据区p中的数据拷贝到新数据区,接着是在new_p的基础上做数据修改的工作(因为是在new_p空间中修改,所以不存在对p的并发访问,因此说RCU是一种免锁机制,原因就在这里),ISR在把数据更新的工作完成后,将new_p赋值给p(p=new_p),最后它会再注册一个回调函数用以在适当的时候释放老指针p。因此,只要对老指针p上的所有引用都结束了,释放p就不会有问题。当中断处理例程做完这些工作返回后,被中断的进程将依然访问到p空间上的数据,也就是老数据,这样的结果是RCU机制所允许的。RCU规则对读取者与写入者之间因指针切换所造成的短暂的资源视图不一致问题是允许的。
接下来关于RCU一个有趣的问题是:何时才能释放老指针。我见过很多书中对此的'回答是:当系统中所有处理器上都发生了一次进程切换。这种程式化的回答常常让刚接触RCU机制的读者感到一头雾水,为什么非要等所有处理器上都发生一次进程切换才可以调用回调函数释放老指针呢?这其实是RCU的设计规则决定的: 所有对老指针的引用只可能发生在rcu_read_lock与rcu_read_unlock所包括的临界区中,而在这个临界区中不可能发生进程切换,而一旦出了该临界区就不应该再有任何形式的对老指针p的引用。很明显,这个规则要求读取者在临界区中不能发生进程切换,因为一旦有进程切换,释放老指针的回调函数就有可能被调用,从而导致老指针被释放掉,当被切换掉的进程被重新调度运行时它就有可能引用到一个被释放掉的内存空间。
现在我们看到为什么rcu_read_lock只需要关闭内核可抢占性就可以了,因为它使得即便在临界区中发生了中断,当前进程也不可能被切换除去。 内核开发者,确切地说,RCU的设计者所能做的只能到这个程度。接下来就是使用者的责任了,如果在rcu的临界区中调用了一个函数,该函数可能睡眠,那么RCU的设计规则就遭到了破坏,系统将进入一种不稳定的状态。
这再次说明,如果想使用一个东西,一定要搞清楚其内在的机制,象上面刚提到的那个例子,即便现在程序不出现问题,但是系统中留下的隐患如同一个定时炸d, 随时可能被引爆,尤其是过了很长时间问题才突然爆发出来。绝大多数情形下,找到问题所花费的时间可能要远远大于静下心来仔细搞懂RCU的原理要多得多。
RCU中的读取者相对rwlock的读取者而言,自由度更高。因为RCU的读取者在访问一个共享资源时,不需要考虑写入者的感受,这不同于rwlock的写入者,rwlock reader在读取共享资源时需要确保没有写入者在 *** 作该资源。两者之间的差异化源自RCU对共享资源在读取者与写入者之间进行了分离,而rwlock的 读取者和写入者则至始至终只使用共享资源的一份拷贝。这也意味着RCU中的写入者要承担更多的责任,而且对同一共享资源进行更新的多个写入者之间必须引入某种互斥机制,所以RCU属于一种"免锁机制"的说法仅限于读取者与写入者之间。所以我们看到:RCU机制应该用在有大量的读取 *** 作,而更新 *** 作相对较少的情形下。此时RCU可以大大提升系统系能,因为RCU的读取 *** 作相对其他一些有锁机制而言,在锁上的开销几乎没有。
实际使用中,共享的资源常常以链表的形式存在,内核为RCU模式下的链表 *** 作实现了几个接口函数,读取者和使用者应该使用这些内核函数,比如 list_add_tail_rcu, list_add_rcu,hlist_replace_rcu等等,具体的使用可以参考某些内核编程或者设备驱动程序方面的资料。
在释放老指针方面,Linux内核提供两种方法供使用者使用,一个是调用call_rcu,另一个是调用synchronize_rcu。前者是一种异步 方式,call_rcu会将释放老指针的回调函数放入一个结点中,然后将该结点加入到当前正在运行call_rcu的处理器的本地链表中,在时钟中断的 softirq部分(RCU_SOFTIRQ), rcu软中断处理函数rcu_process_callbacks会检查当前处理器是否经历了一个休眠期(quiescent,此处涉及内核进程调度等方面的内容),rcu的内核代码实现在确定系统中所有的处理器都经历过了一个休眠期之后(意味着所有处理器上都发生了一次进程切换,因此老指针此时可以被安全释放掉了),将调用call_rcu提供的回调函数。
synchronize_rcu的实现则利用了等待队列,在它的实现过程中也会向call_rcu那样向当前处理器的本地链表中加入一个结点,与 call_rcu不同之处在于该结点中的回调函数是wakeme_after_rcu,然后synchronize_rcu将在一个等待队列中睡眠,直到系统中所有处理器都发生了一次进程切换,因而wakeme_after_rcu被rcu_process_callbacks所调用以唤醒睡眠的 synchronize_rcu,被唤醒之后,synchronize_rcu知道它现在可以释放老指针了。
所以我们看到,call_rcu返回后其注册的回调函数可能还没被调用,因而也就意味着老指针还未被释放,而synchronize_rcu返回后老指针肯定被释放了。所以,是调用call_rcu还是synchronize_rcu,要视特定需求与当前上下文而定,比如中断处理的上下文肯定不能使用 synchronize_rcu函数了。
上面讲的自旋锁,信号量和互斥锁的实现,都是使用了原子 *** 作指令。由于原子 *** 作会 lock,当线程在多个 CPU 上争抢进入临界区的时候,都会 *** 作那个在多个 CPU 之间共享的数据 lock。CPU 0 *** 作了 lock,为了数据的一致性,CPU 0 的 *** 作会导致其他 CPU 的 L1 中的 lock 变成 invalid,在随后的来自其他 CPU 对 lock 的访问会导致 L1 cache miss(更准确的说是communication cache miss),必须从下一个 level 的 cache 中获取。
这就会使缓存一致性变得很糟,导致性能下降。所以内核提供一种新的同步方式:RCU(读-复制-更新)。
RCU 解决了什么
RCU 是读写锁的高性能版本,它的核心理念是读者访问的同时,写者可以更新访问对象的副本,但写者需要等待所有读者完成访问之后,才能删除老对象。读者没有任何同步开销,而写者的同步开销则取决于使用的写者间同步机制。
RCU 适用于需要频繁的读取数据,而相应修改数据并不多的情景,例如在文件系统中,经常需要查找定位目录,而对目录的修改相对来说并不多,这就是 RCU 发挥作用的最佳场景。
RCU 例子
RCU 常用的接口如下图所示:
为了更好的理解,在剖析 RCU 之前先看一个例子:
#include<linux/kernel.h>#include<linux/module.h>#include<linux/init.h>#include<linux/slab.h>#include<linux/spinlock.h>#include<linux/rcupdate.h>#include<linux/kthread.h>#include<linux/delay.h>structfoo{intastructrcu_headrcu}staticstructfoo*g_ptrstaticintmyrcu_reader_thread1(void*data)//读者线程1{structfoo*p1=NULLwhile(1){if(kthread_should_stop())breakmsleep(20)rcu_read_lock()mdelay(200)p1=rcu_dereference(g_ptr)if(p1)printk("%s: read a=%d\n",__func__,p1->a)rcu_read_unlock()}return0}staticintmyrcu_reader_thread2(void*data)//读者线程2{structfoo*p2=NULLwhile(1){if(kthread_should_stop())breakmsleep(30)rcu_read_lock()mdelay(100)p2=rcu_dereference(g_ptr)if(p2)printk("%s: read a=%d\n",__func__,p2->a)rcu_read_unlock()}return0}staticvoidmyrcu_del(structrcu_head*rh)//回收处理 *** 作{structfoo*p=container_of(rh,structfoo,rcu)printk("%s: a=%d\n",__func__,p->a)kfree(p)}staticintmyrcu_writer_thread(void*p)//写者线程{structfoo*oldstructfoo*new_ptrintvalue=(unsignedlong)pwhile(1){if(kthread_should_stop())breakmsleep(250)new_ptr=kmalloc(sizeof(structfoo),GFP_KERNEL)old=g_ptr*new_ptr=*oldnew_ptr->a=valuercu_assign_pointer(g_ptr,new_ptr)call_rcu(&old->rcu,myrcu_del)printk("%s: write to new %d\n",__func__,value)value++}return0}staticstructtask_struct*reader_thread1staticstructtask_struct*reader_thread2staticstructtask_struct*writer_threadstaticint__initmy_test_init(void){intvalue=5printk("figo: my module init\n")g_ptr=kzalloc(sizeof(structfoo),GFP_KERNEL)reader_thread1=kthread_run(myrcu_reader_thread1,NULL,"rcu_reader1")reader_thread2=kthread_run(myrcu_reader_thread2,NULL,"rcu_reader2")writer_thread=kthread_run(myrcu_writer_thread,(void*)(unsignedlong)value,"rcu_writer")return0}staticvoid__exitmy_test_exit(void){printk("goodbye\n")kthread_stop(reader_thread1)kthread_stop(reader_thread2)kthread_stop(writer_thread)if(g_ptr)kfree(g_ptr)}MODULE_LICENSE("GPL")module_init(my_test_init)module_exit(my_test_exit)
执行结果是:
myrcu_reader_thread2:reada=0myrcu_reader_thread1:reada=0myrcu_reader_thread2:reada=0myrcu_writer_thread:writetonew5myrcu_reader_thread2:reada=5myrcu_reader_thread1:reada=5myrcu_del:a=0
RCU 原理
可以用下面一张图来总结,当写线程 myrcu_writer_thread 写完后,会更新到另外两个读线程 myrcu_reader_thread1 和 myrcu_reader_thread2。读线程像是订阅者,一旦写线程对临界区有更新,写线程就像发布者一样通知到订阅者那里,如下图所示。
写者在拷贝副本修改后进行 update 时,首先把旧的临界资源数据移除(Removal);然后把旧的数据进行回收(Reclamation)。结合 API 实现就是,首先使用 rcu_assign_pointer 来移除旧的指针指向,指向更新后的临界资源;然后使用 synchronize_rcu 或 call_rcu 来启动 Reclaimer,对旧的临界资源进行回收(其中 synchronize_rcu 表示同步等待回收,call_rcu 表示异步回收)。
为了确保没有读者正在访问要回收的临界资源,Reclaimer 需要等待所有的读者退出临界区,这个等待的时间叫做宽限期(Grace Period)。
Grace Period
中间的黄色部分代表的就是 Grace Period,中文叫做宽限期,从 Removal 到 Reclamation,中间就隔了一个宽限期,只有当宽限期结束后,才会触发回收的工作。宽限期的结束代表着 Reader 都已经退出了临界区,因此回收工作也就是安全的 *** 作了。
宽限期是否结束,与 CPU 的执行状态检测有关,也就是检测静止状态 Quiescent Status。
Quiescent Status
Quiescent Status,用于描述 CPU 的执行状态。当某个 CPU 正在访问 RCU 保护的临界区时,认为是活动的状态,而当它离开了临界区后,则认为它是静止的状态。当所有的 CPU 都至少经历过一次 Quiescent Status 后,宽限期将结束并触发回收工作。
因为 rcu_read_lock 和 rcu_read_unlock 分别是关闭抢占和打开抢占,如下所示:
staticinlinevoid__rcu_read_lock(void){preempt_disable()}
staticinlinevoid__rcu_read_unlock(void){preempt_enable()}
所以发生抢占,就说明不在 rcu_read_lock 和 rcu_read_unlock 之间,即已经完成访问或者还未开始访问。
Linux 同步方式的总结
资料免费领
学习直通车
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)