互斥锁上try_lock的效率如何？即可能存在多少汇编程序指令，以及它们在两种可能情况下消耗了多少时间（即互斥锁之前已经被锁定或者它是空闲的并且可以被锁定）。
如果您在回答问题时遇到问题，请参阅以下内容（如果真的不清楚）：
如果答案很大程度上取决于操作系统的实现和硬件：请回答它的常见操作系统（例如Linux，Windows，MacOSX），它们的最新版本（如果它们与早期版本有很大不同）和常见的硬件（x86，amd64，ppc，arm）。
如果这也取决于库：以pthread为例。
请回答它们是否完全不同。如果它们不同，请说明差异。即他们做了什么不同的事情？有什么常见的算法？是否存在不同的算法或所有常见系统（如果不清楚的话，上面列表中常见的）是否以相同的方式实现了互斥体？
截至this Meta discussion，这确实应该是一个单独的问题。
此外，我已将此问题作为performance of a lock中的单独问题提出，因为我不确定try_lock是否可能表现不同。也许还取决于实施。然后，请回答它以进行常见实施。这个非常相似/相关的问题显然表明这是一个有待回答的有趣问题。
答案 0 :(得分：2)
互斥是一种独立于任何实现的逻辑结构。因此，对互斥体的操作既不高效也不低效 - 它们只是简单定义。
因此，您的问题类似于询问“汽车的效率如何？”，而不考虑您可能会谈论的汽车类型。
我可以在现实世界中使用烟雾信号，载体鸽子或铅笔和纸张来实现互斥体。我也可以在电脑上实现它们。我可以在Cray 1，Intel Core 2 Duo或我地下室的486上实现某些操作的互斥锁。我可以在硬件中实现它们。我可以在操作系统内核的软件中，或者在用户空间中，或者使用两者的某种组合来实现它们。我可以使用无锁算法来模拟互斥体（但不实现它们），这些算法在关键部分内保证无冲突。
编辑：您的后续编辑无助于此情况。 “在低级语言（如C或其他）中，”大部分都是无关紧要的，因为那时我们正在测量语言实现性能，而且这是最好的滑坡。 “[F] rom pthread或本机系统库提供的任何内容”同样无益，因为正如我所说，有很多方法可以在不同的环境中实现互斥体，这甚至不是一个有用的比较。
这就是为什么你的问题无法回答的原因。