互斥锁上的 try_lock 效率如何？答案

【问题标题】：How efficient is a try_lock on a mutex?互斥锁上的 try_lock 效率如何？
【发布时间】：2010-09-06 14:03:11
【问题描述】：

try_lock 在互斥体上的效率如何？ IE。在这两种可能的情况下，可能有多少汇编指令以及它们消耗了多少时间（即互斥体之前已经被锁定，或者它是空闲的并且可以被锁定）。

如果您在回答问题时遇到问题，这里有一个方法（如果真的不清楚）：

如果该答案很大程度上取决于操作系统的实现和硬件：请回答常见操作系统（例如 Linux、Windows、MacOSX）、最新版本（以防它们与早期版本有很大差异）和常见操作系统硬件（x86、amd64、ppc、arm）。

如果这也取决于库：以 pthread 为例。

如果它们真的完全不同，也请回答。如果它们不同，请说明差异。 IE。他们有什么不同？周围有哪些常见的算法？是否有不同的算法，或者所有常见系统（如果不清楚，上面的列表很常见）是否都以相同的方式实现了互斥锁？

截至this Meta discussion，这确实应该是一个单独的问题。

另外，我已将此问题作为与performance of a lock 分开的问题提出，因为我不确定try_lock 的行为是否会有所不同。也许还取决于实施。再说一遍，请回答常见的实现。而这个非常相似/相关的问题显然表明这是一个可以回答的有趣问题。

【问题讨论】：

真的有必要开始一个与您 2 分钟前问的几乎相同的全新问题吗？特别是考虑到这个问题与我在上一个问题中发现的问题完全相同。
@Gian：嗯，这是一个不同的问题，不是吗？通常，尽可能将单独的问题分开是有帮助的。此外，这个问题的答案可能完全独立于另一个问题。你知道不是这样吗？我不知道，我认为不是。那么请回答问题。 :)
@Gian：在这里阅读：meta.stackexchange.com/questions/39223/…
关于您在每个问题中包含多少详细信息，它们是同一个问题。可以合理地说，在这两种情况下，答案都是“取决于实现”。
我相信我的论点是为什么我认为它是完全复制的，而且似乎其他人也同意我的观点。该元帖子讨论了同一领域中的独立问题。关于包含多少细节以及限制每个细节范围的方式（根本不是），您的问题是相同的。

标签： multithreading locking pthreads mutex

【解决方案1】：

互斥锁是一种独立于任何实现的逻辑结构。因此，对互斥体的操作既不高效也不低效——它们是简单定义的。

因此，您的问题类似于问“汽车的效率如何？”，而没有提及您可能在谈论哪种汽车。

我可以在现实世界中使用烟雾信号、信鸽或铅笔和纸来实现互斥锁。我也可以在计算机上实现它们。我可以在 Cray 1、Intel Core 2 Duo 或我地下室的 486 上实现具有某些操作的互斥锁。我可以在硬件中实现它们。我可以在操作系统内核或用户空间中的软件中实现它们，或者使用两者的某种组合。我可能会使用无锁算法来模拟互斥锁（但不实现它们），这些算法可以保证在关键部分内无冲突。

编辑：您随后的编辑对这种情况没有帮助。 “在低级语言（如 C 或其他语言）中”基本上是无关紧要的，因为那时我们正在测量语言实现性能，这充其量只是一个滑坡。 “[F]from pthread 或本机系统库提供的任何东西”同样无济于事，因为正如我所说，有很多方法可以在不同的环境中实现互斥锁，甚至无法进行有用的比较。

这就是您的问题无法回答的原因。

【讨论】：

好吧，不要只考虑 Linux、MacOSX 和 Windows 上的当前实现。并请描述/为什么该实现从根本上不同于早期/其他实现。请举例说明它在实践中实际实施的不同方式。因为我怀疑在通用 (x86,amd64) 硬件上的通用 (Linux/MacOSX/Win) 操作系统有这么多根本不同的实现。
很抱歉，我的合同价格可应要求提供。否则你可以接受我的回答或留下它:) 我想我现在已经为这个主题投入了足够的时间。也许其他人会通过完整的比较分析提供答案，您可以自己执行或搜索研究文献。
如果您觉得我要求的信息太多，而您的知识不足以回答这个问题，您无需回答。