自旋锁，它们有多有用？
您发现自己在代码中实际使用自旋锁的频率是多少？遇到使用繁忙循环实际上优于使用锁的情况有多常见？
就我个人而言，当我编写某种需要线程安全的代码时，我倾向于使用不同的同步原语对其进行基准测试，就目前而言，使用锁似乎比使用自旋锁提供了更好的性能。无论我实际持有锁的时间有多短，使用自旋锁时收到的争用数量都远远大于使用锁获得的数量(当然，我是在多处理器机器上运行测试的)。
我知道它更有可能在“低级”代码中遇到自旋锁，但我很想知道您是否发现它在更高级的编程中也有用？
回答 10
Stack Overflow用户
发布于 2009-09-21 19:07:06
这取决于你在做什么。在一般的应用程序代码中，您将希望避免自旋锁。
在低级的东西中，你只需要持有几个指令的锁，并且延迟很重要，自旋锁可能是比锁更好的解决方案。但这种情况很少见，特别是在通常使用C#的应用程序中。
Stack Overflow用户
发布于 2009-09-21 19:18:09
在C#中，根据我的经验，“旋转锁”几乎总是比使用锁更糟糕--旋转锁的表现优于锁的情况很少见。
然而，情况并不总是这样。.NET 4正在添加一个System.Threading.SpinLock结构。这在锁被持有很短的时间并且被反复抓取的情况下提供了好处。来自Data Structures for Parallel Programming上的MSDN文档
在期望锁的等待时间较短的情况下，SpinLock提供比其他形式的锁更好的性能。
在执行诸如通过树进行锁定之类的操作时，自旋锁可以胜过其他锁定机制-如果您在每个节点上只有非常非常短的一段时间的锁，那么它们的性能就可以超过传统的锁。我在多线程场景更新的渲染引擎中遇到了这一点-自旋锁的性能优于Monitor.Enter的锁。
Stack Overflow用户
发布于 2009-09-21 19:17:30
在我的实时工作中，特别是在设备驱动程序方面，我已经使用了相当多。事实证明(当我上次计时的时候)等待一个同步对象，比如绑定到硬件中断的信号量，至少会消耗20微秒，而不管中断实际发生需要多长时间。对内存映射硬件寄存器的一次检查，然后是对RDTSC的检查(允许超时，这样您就不会锁定机器)是在高纳秒范围内(基本上是在噪声中)。对于硬件级别的握手，这应该不会花费太多时间，要击败自旋锁真的很难。
https://stackoverflow.com/questions/1456225
复制相似问题
腾讯云开发者
