尝试在互斥锁上执行try_lock操作有多高效？
尝试在互斥锁上执行try_lock操作有多高效？
互斥锁上的try_lock有多高效？也就是说，在两种情况下（即互斥锁在之前已被锁定或之前是自由的且可以锁定）可能有多少汇编指令以及它们消耗了多少时间。
如果您对回答这个问题有困难，这里有一个如何操作的指南（如果真的不清楚的话）：
如果答案在很大程度上取决于操作系统实现和硬件，请为常见的操作系统（如Linux、Windows、MacOSX），以及它们的最新版本（如果它们与早期版本有很大不同）和常见的硬件（x86、amd64、ppc、arm）回答。
如果这也取决于库，请以pthread为例。
请还回答它们是否真的有所不同。如果它们不同，请说明差异。也就是说，它们的不同之处在哪里？周围有什么常见的算法？不同的算法是否存在，或者所有常见系统（根据上述列表来确定）是否都以相同的方式实现了互斥锁？
根据这个Meta讨论，这确实应该是一个独立的问题。
另外，我把这个问题单独提出来，与锁的性能不同，因为我不确定try_lock的行为是否可能不同。也许还取决于实现。再次强调，请回答常见的实现。而且，这个非常相似/相关的问题显然表明这是一个有趣的问题，可以得到回答。
互斥锁是一个独立于任何实现的逻辑构造。因此，对互斥锁的操作既不高效也不低效 - 它们只是被定义出来的。你的问题就像是在没有指明具体车型的情况下问“汽车有多高效”一样。
我可以用烟信号、信鸽或纸和笔在现实世界中实现互斥锁。我也可以在计算机上实现它们。我可以用Cray 1、Intel Core 2 Duo或我地下室里的486来实现互斥锁。我可以用硬件来实现它们。我可以在操作系统内核中以软件方式实现它们，也可以在用户空间中实现，或者两者结合使用。我还可以使用无锁算法来模拟（而不是实现）互斥锁，这些算法在关键部分内保证无冲突。
编辑：你后来的编辑并没有改变情况。“在像C这样的低级语言中”大多不相关，因为那样我们就进入了测量语言实现性能的领域，这最多只能说是一种不精确的比较。“从pthread或者其他本地系统库提供的”同样没有帮助，因为正如我所说，有很多种方式可以在不同的环境中实现互斥锁，这种比较根本没有意义。
这就是为什么你的问题无法回答。
好吧，那就只考虑当前在Linux、MacOSX和Windows上的实现。请描述一下这种实现与之前/其他实现基本上有何不同。请举一些实际上实现方式的不同示例。因为我怀疑常见的（Linux/MacOSX/Win）操作系统在常见的（x86，amd64）硬件上并没有太多根本上不同的实现。
很抱歉，我的合同费用可根据要求提供。否则，你可以接受或放弃我的答案 🙂 我已经花了足够多的时间在这个主题上了，我想。也许其他人会提供一个包含全面比较分析的答案，你可以自己进行，或者搜索研究文献。
如果你觉得我要求的信息太多，你的知识涵盖不够无法回答，那你可以不回答这个问题。