信号量与自旋锁在实践中的成本如何昂贵？
信号量与自旋锁在实践中的成本如何昂贵？
这个问题询问是否可以改进自旋锁，以减少CPU时间而不影响延迟。大量回答提出了C++11、Boost等高级语言概念。\n我最初的想法是使用简单的C信号量，因为发帖者只需要在缓冲区为空或满时阻塞。\n然而，在撰写答案的过程中，我意识到我不知道这些函数的实际开销是多少。直观上看，它应该很小，并且对我来说从未成为优化问题，但是也许与自旋锁相比它是相当大的。显然，这也与系统相关。\n对于这个问题的回答表明，当锁定时间小于一个线程时间片时，自旋锁是首选，但没有给出任何真实世界的指示原因。\n对于这个问题的回答提供了一个在C++中使用自旋锁和pthread_wait的信号量实现的工作示例，但它并不来自任何实际的语言实现。\n在这里，有一个关于互斥锁和信号量之间速度差异的问题，一些人宣称这些差异微不足道，而其他人则说信号量更慢。\n由这个问题链接到的一篇文章暗示，C#中的互斥锁命令在2.4GhZ机器上的实际成本约为50ns（大约100个周期）。但是，不清楚C#的实现是否代表了例如POSIX信号量的纯C实现。\n因此，问题是，实际中使用信号量的开销是多少，进而，如果我只关心延迟（即没有任何维护性原因），我应该何时选择自旋锁？
信号量和自旋锁在实际中的昂贵程度是多少？这个问题的出现原因是什么？解决方法有哪些？
自旋锁是使用处理器指令实现的，这些指令本质上是原子的。因此，获取和释放锁可以非常快速。当你持有锁的时间越长，对锁的争用越多时，性能就会从理想状态下降。因此，自旋锁最适合不经常更新的数据。据我所知，.NET（4.0+）有自己的纯托管自旋锁实现，避免了转换为非托管代码（以及随后的内核访问），这使得开销几乎可以忽略不计。
几乎所有其他类型的锁都基于等待句柄（在.NET领域中的例外是纯托管的Monitor类），除非你在内核空间中编写设备驱动程序，否则性能可能不会有太大差异（因为成本的很大一部分是转换为内核空间和返回的过程）。选择最适合应用程序需求的锁类型。
如果你真的非常关心这个问题，可以进行一些性能测试，模拟预期的工作负载，并对首选选项进行基准测试，以了解它们的性能如何。
+1- 对我来说听起来很好- 在自己的应用程序/硬件/操作系统上进行测试。
根据上述内容，我们可以看出，该问题的出现是因为想要了解在实际应用中，信号量和自旋锁的昂贵程度。作者提到自旋锁使用处理器指令实现，获取和释放锁非常快速，但长时间持有锁和对锁的争用会降低性能。而信号量和其他锁类型基于等待句柄，性能在大多数情况下不会有太大差异。解决方法是选择最适合应用程序需求的锁类型，并进行性能测试以评估各个选项的性能。