自旋锁，它们有多有用？

Question

您发现自己在代码中实际使用自旋锁的频率有多高？使用繁忙循环实际上优于使用锁的情况有多常见？
就我个人而言，当我编写某种需要线程安全的代码时，我倾向于使用不同的同步原语对其进行基准测试，就目前而言，使用锁似乎比使用自旋锁具有更好的性能。无论我实际持有锁的时间有多短，使用自旋锁时收到的争用量都远远大于使用锁时收到的争用量（当然，我在多处理器计算机上运行测试）。

我意识到在“低级”代码中更有可能遇到自旋锁，但我很想知道您是否发现它在更高级的编程中有用？

Answer 1

这取决于你在做什么。在一般应用程序代码中，您需要避免自旋锁。

在低级的东西中，您只需要保持几个指令的锁，并且延迟很重要，自旋锁可能是比锁更好的解决方案。但这种情况很少见，特别是在通常使用 C# 的应用程序中。

Answer 2

在 C# 中，根据我的经验，“自旋锁”几乎总是比获取锁更糟糕 - 自旋锁的性能优于锁的情况很少见。

然而，情况并非总是如此。 .NET 4 正在添加 System.Threading .SpinLock结构。这在锁被持有很短时间并且被重复抓住的情况下提供了好处。来自 MSDN 文档 并行编程的数据结构：

在预期锁定等待时间较短的场景中，SpinLock 比其他形式的锁定提供更好的性能。

在您执行诸如通过树锁定之类的操作的情况下，自旋锁可以胜过其他锁定机制 - 如果您仅在每个节点上锁定非常非常短的时间，则它们可以胜过传统锁。我在具有多线程场景更新的渲染引擎中遇到了这个问题，在某一时刻，旋转锁的性能优于 Monitor.Enter 的锁定。

Answer 3

对于我的实时工作，特别是设备驱动程序，我使用了相当多的它们。事实证明（当我上次计时时）等待同步对象（例如与硬件中断相关的信号量）至少会花费 20 微秒，无论中断发生实际需要多长时间。对内存映射硬件寄存器进行一次检查，然后检查 RDTSC（以允许超时，这样就不会锁定机器）处于高纳秒范围内（基本上降低了噪声）。对于根本不需要花费太多时间的硬件级握手来说，击败自旋锁确实很困难。

Answer 4

我的 2c：如果您的更新满足某些访问条件，那么它们是很好的自旋锁候选者：

• 快速，即您将有时间在单个线程量子中获取自旋锁、执行更新并释放自旋锁，以便在持有自旋锁时，您不会被抢占
• 本地化，您更新的所有数据最好都在已加载的单个页面中，您不希望在持有自旋锁时出现 TLB 未命中，并且您绝对不希望页错误交换读取！
• 原子你不需要任何其他锁来执行操作，即。永远不要等待自旋锁下的锁。

对于任何有可能产生收益的东西，您应该使用通知锁结构（事件、互斥体、信号量等）。

Answer 5

自旋锁的一个用例是，如果您期望争用非常少，但实际上将会有很多争用。如果不需要支持递归锁定，则可以在单个字节中实现自旋锁，并且如果争用非常低，则 CPU 周期浪费可以忽略不计。

对于实际用例，我经常拥有包含数千个元素的数组，其中可以安全地并行更新数组的不同元素。两个线程尝试同时更新同一元素的几率非常小（低争用），但我需要为每个元素加一把锁（我将拥有很多元素）。在这些情况下，我通常分配一个与我并行更新的数组大小相同的 ubyte 数组，并内联实现自旋锁（在 D 编程语言中）：

while(!atomicCasUbyte(spinLocks[i], 0, 1)) {}
    myArray[i] = newVal;
atomicSetUbyte(spinLocks[i], 0);

另一方面，如果我必须使用常规锁，我必须分配一个指向对象的指针数组，然后为该数组的每个元素分配一个互斥对象。在上述场景中，这纯粹是一种浪费。

Answer 6

如果您有对性能至关重要的代码并且您已确定它需要比当前速度更快并且您已确定关键因素是锁定速度，那么它'尝试使用自旋锁是个好主意。在其他情况下，为什么还要麻烦呢？普通锁更容易正确使用。

Answer 7

请注意以下几点：

1. 大多数互斥体的实现在线程实际未调度之前会旋转一段时间。因此，很难将这些互斥锁与纯自旋锁进行比较。

2. 多个线程在同一个自旋锁上“尽可能快地”旋转将占用所有带宽并大大降低程序效率。您需要通过在旋转循环中添加 noop 来添加微小的“睡眠”时间。

Answer 8

您几乎不需要在应用程序代码中使用自旋锁，如果有的话您应该避免使用它们。

我没有任何理由在正常操作系统上运行的 C# 代码中使用自旋锁。繁忙的锁在应用程序级别上主要是一种浪费 - 旋转可能会导致您使用整个 cpu 时间片，而锁会在需要时立即导致上下文切换。

在某些情况下，拥有 nr 个线程 = nr 个处理器/核心的高性能代码可能会受益，但如果您需要该级别的性能优化，您可能会制作下一代 3D 游戏，在同步基元较差的嵌入式操作系统上工作，创建一个操作系统/驱动程序或在任何情况下不使用 c#。

Answer 9

我在我的 HLVM 中使用了自旋锁来实现垃圾收集器的 stop-the-world 阶段项目，因为它们很简单，而且是一个玩具虚拟机。然而，在这种情况下，自旋锁可能会适得其反：

Glasgow Haskell 编译器的垃圾收集器中的一个性能错误非常烦人，以至于它有一个名字，“最后一次核心减速"。这是他们在 GC 中不当使用自旋锁的直接后果，并且由于其调度程序而在 Linux 上加剧，但事实上，只要其他程序竞争 CPU 时间，就可以观察到这种影响。

此处 可以看出，影响的不仅仅是最后一个核心此处，Haskell 程序在超过 5 个核心时发现性能下降。

Answer 10

使用自旋锁时请始终牢记以下几点：

• 快速用户模式执行。
• 同步单个进程中的线程，或者同步多个进程（如果在共享内存中）。
• 在拥有该对象之前不会返回。
• 不支持递归。
• “等待”时消耗 100% 的 CPU。

我个人见过很多死锁，只是因为有人认为使用自旋锁是个好主意。

使用自旋锁时要非常小心

（这一点我怎么强调都不为过）。