信号量和自旋锁的价格在实际中有多高？
This question询问是否可以以不影响延迟但使用较少CPU时间的方式改进自旋锁。大量的答案显示了C++11、Boost等高级语言概念。
我的第一个想法是使用一个简单的C信号量，因为只有当缓冲区为空或满时，海报才需要阻塞。
然而，在写答案的过程中，我意识到我不知道这些函数的实际开销是什么。从直觉上看，它看起来应该很小，对我来说从来都不是一个优化问题，但也许它是实质性的，而不是自旋锁。这大概也是与系统有关的。
this question的答案表明，当锁定少于一个线程量子时，倾向于使用自旋锁，但没有给出实际的原因指示。
this question的答案提供了一个C++中信号量实现的工作示例，该实现使用了正文中带有pthread_wait的自旋锁，但它不是从任何实际的语言实现中获取的。
在here上，一个关于互斥量和信号量之间速度差异的问题被一些人宣布为无关紧要。其他人则认为信号量较慢。
this question链接的一篇文章指出，在2.4GhZ机器(so ~100周期)上，用于互斥对象的C#锁命令的实际成本为50 so。但是，尚不清楚C#的实现是否代表POSIX信号量的直接C实现。
因此，问题是，信号量使用的开销(如在实践中的)是什么?因此，如果我只关心延迟(即由于某种原因而不是可维护性)，什么时候我应该更喜欢自旋锁？
回答 1
Stack Overflow用户
发布于 2013-04-25 22:49:51
我绝不是这方面的专家，所以你应该接受我的建议，这取决于你的情况。
自旋锁是使用本质上是原子的处理器指令来实现的。因此，获取和释放锁的速度非常快。性能从这个理想下降，你持有锁的时间越长，锁的争用就越多。因此，它最适合于不经常更新的数据。Afaik .NET (4.0+)有自己的托管专用自旋锁实现，避免了向非托管代码(以及随后的内核访问)的转换，这使得开销几乎微不足道。
几乎所有其他锁类型都是基于WaitHandles ( .NET-land中的例外，无论如何是托管专用监视器类)，并且除非您正在编写运行在内核空间中的设备驱动程序，否则性能可能不会有太大的变化(因为很大一部分成本是过渡到内核空间和后台)。选择最适合应用程序需要的锁类型。
如果您真的很关心这个问题，那么就把一些模拟预期工作负载的性能测试放在一起，并对您喜欢的选项进行基准测试，看看它们是如何堆积起来的。
https://stackoverflow.com/questions/16225293
复制相似问题
腾讯云开发者
