Board logo

标题: 读写自旋锁详解,第 3 部分 可扩展性研究(1) [打印本页]

作者: look_w    时间: 2018-4-23 15:37     标题: 读写自旋锁详解,第 3 部分 可扩展性研究(1)

基于简单共享变量的读写自旋锁的不足本系列文章的第 2 部分中给出的实现都基于简单共享变量,简洁实用,但在大规模多核、NUMA 系统上可扩展性较差。我们说某个读写自旋锁的实现是可扩展的,通俗地讲是指在线程访问模式(读者写者数目之比、各自到来的频率及持有锁的时间)不变的前提下增加处理器的个数,线程的吞吐量(单位时间内获得锁的线程数目)也随之大幅增加。如果能接近线性(甚至由于缓存的影响使得超线性)增加,我们说该实现是高可扩展的。
基于简单共享变量的读写自旋锁的可扩展性较差本质上是因为操作共享变量的代价过大:如果系统不能保证缓存的一致性,读写共享变量导致总线的流量激增;即使提供了一致性的缓存,频繁的写操作也会增大处理器间的缓存同步开销。具体而言有 3 点:
因此我们可以针对上述 3 点,分别提出相应的改进策略:
基于单向链表的公平读写自旋锁首先我们考虑如何让等待线程只在局部变量上自旋,这涉及四个问题:
我们很容易想到可以用单向链表将申请线程组织成一个队列,每个线程能够通过指针寻找到自己的所有后继,而且线程申请锁的顺序与线程在队列中的位置保持一致,因此用单向链表可以实现一个公平的读写自旋锁 [3]。
凭空想象算法似乎有些困难,我们还是先在草稿纸上画一个示意图,有了感性认识之后再考虑数据结构和算法的细节。
图 1. 基于单向链表的公平读写自旋锁示意图从图上可以看到,为了构建单向链表,每个线程必须有一个自己私有的链表节点数据结构,里面至少包含三个域:自身角色 type、自旋变量 waiting 和指向直接后继的 next 指针。我们还需要一个指向链表尾部的指针 tail,新到的线程通过它可以获得其直接前驱,从而将自己插入链表。这个 tail 指针应当放到锁的数据结构中。
值得注意的是,插入链表这个动作并不是原子的,至少需要 2 个操作:原子地获得 tail 指针并将其指向自己;将直接前驱的 next 指针指向自己。但是线程的直接前驱随时可能释放锁,并继续申请锁而重用其数据结构,因此需要约束线程的行为以保证单向链表的一致性。我们规定:线程释放锁之前必须检查自身是否存在直接后继线程,如果存在则保证在直接后继插入链表之后才能释放锁。这可以通过检查 tail 和 next 指针实现。
连续的读者可以同时持有锁,但是它们并不一定按照申请的顺序释放锁,故而难以在释放锁的时候继续保持这些读者间的链表结构。这是因为我们使用的是单向链表,释放锁的读者很难用简单高效的方法将其节点数据结构从链表中摘下 [4](即使保存了直接前驱的指针,也可能已经失效),而且该读者也许需要继续申请锁而重用该数据结构,导致其尚未释放锁的直接前驱读者也不能再使用 next 指针遍历后继。单向链表的结构被破坏带来如下 2 个挑战:
一种直观简单的解决方案是用一个计数器 nr_readers 记录当前同时持有锁的数目,读者获得锁前原子递增 nr_readers;释放锁的时候原子递减,如果递减后 nr_readers 为 0,表示自己此刻是最后一个持有锁的读者。此外还需要一个记录等待线程中的第一个写者的指针 next_writer。这两个变量也应当放到锁的数据结构中。
读者并发还带来一个棘手的问题。还是以图 2 为例,当读者 A1获得锁时,如果此时知道 A2已经到来了(通过检查自己的 next 指针),那么应该由 A1通知 A2。但是可能 A2到来的时候 A1已经在访问共享资源或者正在释放锁,那么 A2应该自行获得锁。因为获得锁涉及到原子递增 nr_readers,所以 A1和 A2必须达成一致。我们的方案是:读者到来时先检查其直接前驱读者是否还在自旋,若是,则原子地在其前驱的节点数据结构中标记一个特殊值。如果标记成功,表明前驱尚未结束自旋,那么由前驱负责通知;如果标记失败,说明前驱已经退出自旋而获得锁,那么读者直接获得锁。标记值可以选得有意义一些,这儿我们选择线程的角色,于是线程很容易知道直接后继的类型,而不用通过 next 指针进一步查看。我们在节点数据结构中增加变量 successor_type。
下面我们详细阐述读写自旋锁的算法。假设申请线程为 A。
A 是读者,申请锁:
A 是读者,释放锁:
A 是写者,申请锁:
A 是写者,释放锁:
具体代码如清单 5 所示,有兴趣的读者朋友可以尝试证明一下正确性。




欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0