# 23.3 RCU实现(1) - 基本实现

一种可能的解决方案是：数据读取者完全不使用锁。在有些场景数据读取者可以直接读数据，只有数据的写入者才需要锁。我们接下来快速的看一下能不能让数据读取者在不上锁的时候直接读取链表。假设我们有个链表，链表元素中存的数据是字符串，我们将读取链表中的数据。如果没有数据的写入者，那么不会有任何问题。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MTxW4K2O6HdaihA0S-n%2F-MTyxDI3QZh1YZp9ubW_%2Fimage.png?alt=media\&token=d7b2bb76-7521-4349-8a52-09d1313921c1)

接下来我们看一下存在数据写入者时的三种可能场景：

* 首先是数据的写入者只修改了链表元素的内容，将链表元素中的字符串改成了其他的字符串。
* 第二种场景是数据写入者插入了一个链表元素。
* 第三种场景是数据写入者删除了一个链表元素。

因为RCU需要分别考虑这三种场景，我们将会分别审视这三种场景并看一下同时发生数据的读写会有什么问题？

* 如果数据写入者想要修改链表元素内的字符串，而数据读取者可能正在读取相同字符串。如果不做任何特殊处理，数据读取者可能会读到部分旧的字符串和部分新的字符串。这是我们需要考虑的一个问题。
* 如果数据写入者正在插入一个链表元素，假设要在链表头部插入一个元素，数据写入者需要将链表的头指针指向新元素，并将新元素的next指针指向之前的第一个元素。这里的问题是，数据的写入者可能在初始化新元素之前，就将头指针指向新元素，也就是说这时新元素包含的字符串是无效的并且新元素的next指针指向的是一个无效的地址。这是插入链表元素时可能出错的地方。
* 如果数据写入者正在删除一个链表元素，我们假设删除的是第一个元素，所以需要将链表的头指针指向链表的第二个元素，之后再释放链表的第一个元素。这里的问题是，如果数据读取者正好在读链表的第一个元素，而数据写入者又释放了这个元素，那么数据读取者看到的是释放了的元素，这个链表元素可能接下来被用作其他用途，从数据读取者的角度来说看到的是垃圾数据。

如果我们完全不想为数据读取者提供任何锁，那么我们需要考虑这三个场景。我将不会讨论数据写入者对应的问题，因为在整个课程中我将会假设数据写入者在完成任何操作前，都会使用类似spinlock的锁。

我们不能直接让数据读取者在无锁情况下完成读取操作，但是我们可以修复上面提到的问题，这就带出了RCU（Read Copy Update）这个话题。RCU是一种实现并发的特殊算法，它是一种组织数据读取者和写入者的方法，通过RCU数据读取者可以不用使用任何锁。RCU的主要任务就是修复上面的三种数据读取者可能会陷入问题的场景，它的具体做法是让数据写入者变得更加复杂一些，所以数据写入者会更慢一些。除了锁以外它还需要遵循一些额外的规则，但是带来的好处是数据读取者因为可以不使用锁、不需要写内存而明显的变快。

在之前讨论的第一个场景中，数据写入者会更新链表元素的内容。RCU将禁止这样的行为，也就是说数据写入者不允许修改链表元素的内容。假设我们有一个链表，数据写入者想要更新链表元素E2。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MTzFk-0dKS9HouYRufP%2F-MU1Ej2qog6TCcPn16XH%2Fimage.png?alt=media\&token=9c49c816-dd7c-4fb0-b0e7-64c2d4993529)

现在不能直接修改E2的内容，RCU会创建并初始化一个新的链表元素。所以新的内容会写到新的链表元素中，之后数据写入者会将新链表元素的next指针指向E3，之后在单个的写操作中将E1的next指针指向新的链表元素。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MU1LMpbNASQ0YVs3wW0%2F-MU1LQD1370XvuyqYR-o%2Fimage.png?alt=media\&token=af1739d7-c0e2-44f7-a38c-28c44531ef96)

所以这里不是修改链表元素的内容，而是用一个包含了更新之后数据的新链表元素代替之前的链表元素。对于数据读取者来说，如果遍历到了E1并正在查看E1的next指针：

* 要么看到的是旧的元素E2，这并没有问题，因为E2并没有被改变；
* 要么看到的是新版本的E2，这也没有问题，因为数据写入者在更新E1的next指针之前已经完全初始化好了新版本的E2。

不管哪种情况，数据读取者都将通过正确的next指针指向E3。这里核心的点在于，数据读取者永远也不会看到一个正在被修改的链表元素内容。

> 学生提问：旧的E2和E3之间的关系会被删除吗？
>
> Robert教授：会被保留。这是个好问题，并且这也是RCU中较为复杂的主要部分，现在我们假设旧的E2被保留了。
>
> 学生提问：我们并不用担心E2和E3之间的关系，因为在普通的实现中，E2也会被释放，就算没有RCU我们也不用担心这里的关系，是吗（注，这里应该说的是GC会回收E2）？
>
> Robert教授：这里的问题是，在我们更新E1的next指针时，部分数据读取者通过E1的旧的next指针走到了旧的E2，所以当完成更新时，部分数据读取者可能正在读取旧的E2，我们最好不要释放它。

这里将E1的next指针从旧的E2切换到新的E2，在我（Robert教授）脑海里，我将其称为committing write。这里能工作的部分原因是，单个committing write是原子的，从数据读取者的角度来说更新指针要么发生要么不发生。通过这一条不可拆分的原子指令，我们将E1的next指针从旧的E2切换到的新的E2。写E1的next指针完成表明使用的是新版本的E2。

这是对于RCU来说一个非常基本同时也是非常重要的技术，它表示RCU主要能用在具备单个committing write的数据结构上。这意味着一些数据结构在使用RCU时会非常的奇怪，例如一个双向链表，其中的每个元素都有双向指针，这时就不能通过单个committing write来删除链表元素，因为在大多数机器上不能同时原子性的更改两个内存地址。所以双向链表对于RCU来说不太友好。相反的，树是一个好的数据结构。如果你有一个如下图的树：

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MU1L_nHYUk5KiCrVvdA%2F-MU1enG3B_zUYijqt0t6%2Fimage.png?alt=media\&token=91cdadde-a260-4f6b-9c70-d4b7d0649f05)

如果我们要更新图中的节点，我们可以构造树的虚线部分，然后再通过单个committing write更新树的根节点指针，切换到树的新版本。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MU1L_nHYUk5KiCrVvdA%2F-MU1fklesb9gdjbgNn3-%2Fimage.png?alt=media\&token=b0b8b3aa-2566-4664-aa14-272fa9234bc1)

数据写入者会创建树中更新了的那部分，同时再重用树中未被修改的部分，最后再通过单个committing write，将树的根节点更新到新版本的树的根节点。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MU1L_nHYUk5KiCrVvdA%2F-MU1h3QOW8M3u5MfEXFY%2Fimage.png?alt=media\&token=2ffcb4d7-1d57-4e2c-a79e-506fc6d04235)

但是对于其他的数据结构，就不一定像树一样能简单的使用RCU。以上就是实现RCU的第一部分。