论文分享 SANL：可扩展NUMA-Aware锁

Scalable Adaptive NUMA-Aware Lock 论文学习笔记

关于

本次论文分享的题目是 Scalable Adaptive NUMA-Aware Lock。本篇论文主要是针对NUMA环境下，可扩展的同步锁进行的研究。本论文提出的SANL锁结合了in-place lock以及delegation lock的优点，并针对NUMA环境进行了优化。

本文将主要记录论文中的核心内容，并在最后一部分记录阅读此论文时的思考。

研究背景

此论文的研究对象是可扩展的锁，针对的具体可扩展性是多核，非对称内存访问模型的情况（NUMA）。

原来使用的锁包括以下两种：

• In-place locks 代表着一类算法

  这种算法在进入CS区域之前会等待一个共享的变量。本质是在CS区域共享数据：导致了Cache失效率。

  例如Spin Lock 就是In-place locks的一种。

  这种算法在可扩展环境下的问题：

  • 首先等待不具有扩展性，不能平分到多个核上
  • 再随着核的数量的增加，对于共享变量的竞争

• delegation locks 代表着一类算法

  该类算法的核心思路是用一个复杂的服务器线程来处理所有对于CS区域的请求。（所有的实际修改是在这个服务器线程上完成？）这样可以避免Cache失效等问题（都在一个地方改）。

  这种算法在可扩展环境下的问题：

  这种算法局限于客户端与服务器之间的通讯带宽。

  在NUMA环境下的特殊：

  在NUMA环境下表现失常是因为没有针对NUMA的特性进行优化。

  对于跨节点的内存访问，（可能是在传送请求的时候用到）。

• 总的来说：

  当在CS区域中的时间占总程序时间比较少的时候：利用In-Place比较好

  当在CS区域中的时间占总程序时间比较多的时候：利用delegation比较好

这两种锁只在一定的环境以及配置下才能拥有良好的性能。

本文介绍的锁SANL，拥有以下特性：

1. 可以在不同的竞争层级在In-place以及delegation中间选择。结合了两种的优点
2. 针对delegation在NUMA中进行优化。引入了一种新的策略，在选择锁服务器时考虑了节点之间的距离以及服务器的利用率。

SANL 具体实现思路

下图为SANL的整体实现流程：

如何在In-place与Delegation之间选择：

1. 每个线程计算本地的竞争层级$C_{l}$，并根据$C_{l}$计算全局竞争层级$C_{g}$
2. 对比全局竞争层级$C_{g}$与门槛$θ_{l}$，如果小于则进入In-place模式，如果大于就进入Delegation模式。

Delegation针对NUMA环境下的具体优化：

1. 进入Delegation模式后，所有的线程均尝试Trylock，成功获取锁的线程成为第一代服务器，没有获取锁的成为客户端。

2. 客户端对于当前锁的竞争层级进行评估（应该还包括了与当前服务器传输延迟等）。若小于$θ_{f}$，则进入自由模式。若大于$θ_{f}$，则进入限制模式。

3. 当处于自由模式时，无论服务器节点是否处于本地，均会向服务器发送请求。

4. 当处于限制模式时，有两种情况：

   1. 服务器节点在本地

      可以直接发送请求到服务器。

   2. 服务器节点不在本地

      这时候需要等待。等待下面两个事件发生：

      1. 当竞争层级下降至$θ_{f}$时，转换为自由模式，并向服务器节点发送请求。
      2. 当服务器转换到本地节点，或者本身转换成服务器节点，就可以发送或者处理请求了。

Delegation针对饥饿的解决方法：

可能面对的饥饿情况：

1. 第一种是服务器节点的饥饿：需要不断处理别的节点的CS请求，导致无法执行自己的代码。
2. 第二种是远处节点的饥饿：一直轮不到远处节点执行请求，导致饥饿。

针对这两种饥饿，设置了最长服务器时间$T_{s}$，以及最短服务间隔时间$T_{w}$

In-place与delegation选择机制

如上面总流程所述，每个线程计算本地的竞争层级$C_{l}$，并根据 Cl