RCU到底是什么？为什么快？为什么可以读写并行？

RCU经典文献

• What is RCU, Fundamentally?
• What is RCU? Part 2: Usage
• RCU part 3: the RCU API
• linux kernel
• RCU作者的主页介绍

这几个连接简直就是一个宝藏&＃xff0c;里面的干活很多很多&＃xff01;&＃xff01;&＃xff01;有时间一定要多看看。下文中的内容是看第一个和第二个链接的笔记和整理。直接观看原文&＃xff0c;效果更佳。

RCU锁特点介绍

Read-copy_update(简称RCU)技术是一种数据同步机制。常见的数据同步机制有&＃xff1a;互斥锁&＃xff0c;自旋锁&＃xff0c;读写锁&＃xff0c;顺序锁&＃xff0c;信号量等手段。而RCU锁是一种比较高效的并发编程技术&＃xff0c;它与2002年10月被添加到Linux内核中&＃xff0c;在很多场景中它是用来替代读写锁的。

RCU锁的特点有&＃xff1a;

• 允许读写同时进行
• 任意读&＃xff1b;写操作时先拷贝一个副本&＃xff0c;在副本上进行修改、发布&＃xff0c;并在合适时间释放原来的旧数据
• 读端不存在睡眠、阻塞、轮询&＃xff0c;不会形成死锁&＃xff0c;相比读写锁效率更高。

RCU也有自己的缺点&＃xff1a;

• 低优先级的读操作可阻塞高优先级的写操作
• 宽限期可能比较长

这是由于RCU 写操作完毕后&＃xff0c;会等待读端的完毕&＃xff0c;等所有的读操作完毕后&＃xff0c;宽限期结束&＃xff0c;此时写端才会将资源释放。这里没有区分优先级&＃xff0c;因此低优先级的读操作可能会影响到高优先级的写操作。

其实&＃xff0c;RCU技术的特点还不仅如此&＃xff0c;而有一个更重要的特点&＃xff1a;多核扩展性。RCU虽然我们将其称之为RCU锁&＃xff0c;但它并没有采用锁技术&＃xff0c;而读写锁则是一个真正的锁&＃xff0c;在扩展性上很差&＃xff0c;设备CPU核越多&＃xff0c;锁的竞争会越激烈&＃xff0c;效率会越低。因此在现在很多的实现中&＃xff0c;越来越注重无锁技术的实现。 下图是在文章What is RCU? Part 2: Usage中的一张RCU和rwlock在多核扩展性上对比图片&＃xff1a;

RCU中常见问题

1. 有没有使用引用计数

关于RCU实现原理还有一个误解&＃xff1a;RCU采用了引用计数的方式确定是否存在读者。 这个观点也是错的。

首先RCU并没有采用引用计数的机制&＃xff0c;而是采用了一种非常简单的技术来实现&＃xff1b;其次如果非要深究到底有没有引用计数&＃xff0c;按照What is RCU? Part 2: Usage中的说法是“RCU is a Restricted Reference-Counting Mechanism”&＃xff0c;但RCU本质上是没有采用引用计数的机制。它的解释如下&＃xff1a;

“rcu_read_lock() 语句可以被认为是获取对 p 的引用&＃xff0c;相当于一个引用计数。因为在 rcu_dereference() 分配给 p 之后开始的宽限期不可能在我们到达匹配的 rcu_read_unlock() 之前结束。 这种引用计数方案受到限制&＃xff0c;因为我们不允许在 RCU 读端临界区中阻塞&＃xff0c;也不允许我们将 RCU 读端临界区从一个任务切换到另一个任务“。

虽然有点像引用计数&＃xff0c;但绝对不是。

至于它怎么实现&＃xff1a;检测是否有人在引用当前变量呢&＃xff1f; 我在下面介绍下

2. RCU既然没有使用引用计数&＃xff0c;那又是确定是否存在读者引用之&＃xff1f;

RCU 读锁加锁和去锁最基本的函数是&＃xff1a;

#define rcu_read_lock() preempt_disable()#define rcu_read_unlock() preempt_enable()


加锁实际上是禁止上下文切换&＃xff1b;而解锁是允许上下文切换。它们是一个全局设置&＃xff0c;不与任何一项锁绑定。这也是为啥RCU读锁不需要任何参数的原因。

基于此&＃xff0c;便可以通过让CPU进行一次上下文切换来实现检测读端是否完成&＃xff0c;而不必跟踪每一个引用的进程。 这是一个RCU非常重要的特点

进行这个操作是&＃xff1a;synchronize_rcu(), 这个函数在内核中实现有点复杂&＃xff0c;它毕竟还需要考虑中断&＃xff0c;热插拔等因素。如果只考虑RCU部分&＃xff0c;它的功能可以概括为&＃xff1a;

第一个函数用来遍历所有的CPU&＃xff1b;第二行run_on()函数用来将当前线程切换到指定的CPU上。如果这个任务顺利完成&＃xff0c;则说明所有的核已经经历过一次上下文切换&＃xff0c;此刻必定读端已经结束&＃xff0c;否则无法触发切换。

关于这里&＃xff0c;我曾经有一个疑问&＃xff1a;假如最初CPU1读端结束&＃xff0c;执行了一次上下文切换&＃xff1b;然后在等待其他CPU过程中&＃xff0c;又再次进入RCU读临界区&＃xff0c;如果此时释放&＃xff0c;会导致严重后果吗&＃xff1f; 有点类似于下图(黄色部分表示可以进行上下文切换)

不过后来想明白了。以替换一个节点为例进行说明&＃xff1a;

• 链表最初状态如下&＃xff1a;
  

• 插入一个元素时&＃xff0c;先复制一个副本&＃xff0c;再次基础上修改&＃xff0c;然后完成发布
  从此刻开始&＃xff0c;rcu宽限期也开始。在发布之前的RCU读端访问的是2号节点(如果有的话)&＃xff0c;发布之后&＃xff0c;新来的RCU读端读取的是2_new新节点。这是RCU的一个重要特点&＃xff0c;实时性很好。

  这里还没有完&＃xff0c;旧的2号节点还没有被释放。

• 更新操作&＃xff08;资源回收&＃xff09;