Linux的RCU锁机制

看了一堆RCU的文档，总结一下，这玩意儿实际编程用得不多，权当自娱自乐

https://www.ibm.com/developerworks/cn/linux/l-rcu/

LDD3rd中 linux同步机制 章节有对RCU比较透彻的介绍

http://hi.baidu.com/j_fo/blog/item/6e7f74c60711381d9c163df2.html

http://www.rdrop.com/users/paulmck/rclock/

http://lse.sourceforge.net/locking/rcupdate.html

http://lwn.net/Articles/262464/

http://lwn.net/Articles/263130/

http://lwn.net/Articles/264090/

RCU的原理总结如下：

RCU(Read-Copy Update)，顾名思义就是读-拷贝修改，它是基于其原理命名的。对于被RCU保护的共享数据结构，读者不需要获得任何锁就可以访问它，但写者在访问它时首先拷贝一个副本，然后对副本进行修改，最后使用一个回调（callback）机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。

因此RCU实际上是一种改进的rwlock，读者几乎没有什么同步开销，它不需要锁，不使用原子指令，而且在除alpha的所有架构上也不需要内存栅（Memory Barrier），因此不会导致锁竞争，内存延迟以及流水线停滞。不需要锁也使得使用更容易，因为死锁问题就不需要考虑了。写者的同步开销比较大，它需要延迟数据结构的释放，复制被修改的数据结构，它也必须使用某种锁机制同步并行的其它写者的修改操作。读者必须提供一个信号给写者以便写者能够确定数据可以被安全地释放或修改的时机。有一个专门的垃圾收集器来探测读者的信号，一旦所有的读者都已经发送信号告知它们都不在使用被RCU保护的数据结构，垃圾收集器就调用回调函数完成最后的数据释放或修改操作。 RCU与rwlock的不同之处是：它既允许多个读者同时访问被保护的数据，又允许多个读者和多个写者同时访问被保护的数据（注意：是否可以有多个写者并行访问取决于写者之间使用的同步机制），读者没有任何同步开销，而写者的同步开销则取决于使用的写者间同步机制。但RCU不能替代rwlock，因为如果写比较多时，对读者的性能提高不能弥补写者导致的损失。

读者在访问被RCU保护的共享数据期间不能被阻塞，这是RCU机制得以实现的一个基本前提，也就说当读者在引用被RCU保护的共享数据期间，读者所在的CPU不能发生上下文切换，spinlock和rwlock都需要这样的前提。写者在访问被RCU保护的共享数据时不需要和读者竞争任何锁，只有在有多于一个写者的情况下需要获得某种锁以与其他写者同步。写者修改数据前首先拷贝一个被修改元素的副本，然后在副本上进行修改，修改完毕后它向垃圾回收器注册一个回调函数以便在适当的时机执行真正的修改操作。等待适当时机的这一时期称为grace period，而CPU发生了上下文切换称为经历一个quiescent state，grace period就是所有CPU都经历一次quiescent state所需要的等待的时间。垃圾收集器就是在grace period之后调用写者注册的回调函数来完成真正的数据修改或数据释放操作的。

读取者在访问RCU被保护的共享数据期间不能被阻塞这点很重要，这保证了这段读取代码是原子的，只要读取者relinquish了CPU，这次动作的在当前CPU上引用计数就为0，下一次再进入的话需要继续调用rcu_read_lock/rcu_read_unlock。因此只要所有的CPU都被调度一次，这时就可以保证被RCU保护的共享数据不会再有读引用计数，此时写操作就可以释放空间了，一般就是调一个kfree完事。

如何调用在实际场景中使用RCU本文没有提及，目前对于链表操作提供了一些宏，至于其他数据结构，请参考相关文档