如何评估无锁队列的性能？
我已经使用http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf中解释的危险指针方法实现了一个无锁队列，使用了用于实现的GCC CAS指令和用于线程本地结构的pthread本地存储。我现在正在尝试评估我编写的代码的性能，特别是我正在尝试将此实现与使用锁(pthread mutexes)来保护队列的实现进行比较。
我之所以在这里问这个问题，是因为我试着将它与“锁定”队列进行了比较，我发现与无锁实现相比，这具有更好的性能。我尝试的唯一测试是在4核x86_64机器上创建4个线程，在队列上执行10.000.000个随机操作，它比无锁版本快得多。
我想知道你是否可以建议我一个方法来遵循，例如，我必须在队列上测试哪种操作，以及我可以使用哪种工具来查看我的无锁代码在哪里浪费时间。
我还想知道，是否有可能仅仅因为4个线程不足以看到重大改进而导致无锁队列的性能变差……
谢谢
回答 2
Stack Overflow用户
发布于 2011-09-27 23:22:01
真正的问题是，您正在针对哪些工作负载进行优化。如果拥塞很少见，那么现代操作系统上的锁结构可能不会太糟糕。他们主要在幕后使用CAS指令，只要它们在快速路径上。因为这些都是非常优化的，所以很难用你自己的代码来击败它们。
我们自己的实现只能在拥塞的部分取得实质性的胜利。如果平均队列长度比并行攻击的线程数长得多，那么队列上的随机操作(你的问题不太精确)可能不会做到这一点。因此，您必须确保队列是短的，可能是通过引入关于在队列太长或太短时选择的随机操作的偏差。然后，我还会为系统分配至少两倍于内核的线程数。这将确保等待时间(对于内存)不会偏向于锁版本。
Stack Overflow用户
发布于 2014-04-27 12:34:21
在我看来，最好的方法是通过分析code.Introduce (无锁机制)来识别应用程序中具有锁的热点，并再次进行同样的测量。正如其他发贴者已经提到的，在较低的规模(线程数量、应用程序规模、核心数量)下可能没有显著的改进，但随着system.This规模的扩大，您可能会看到吞吐量的提高，因为死锁情况已经消除，线程总是在向前发展。
另一种看待无锁方案优点的方法是，在某种程度上，可以将系统状态与应用程序性能解耦，因为没有内核/调度器参与，并且除了CAS是hw指令外，大部分代码都是userland。
对于竞争激烈的锁，一旦获得锁，线程就会阻塞并被调度，这基本上意味着它们被放置在运行队列的末尾(对于特定的优先级).Inadvertently这将应用程序链接到系统状态，应用程序的响应时间现在取决于运行队列长度。
就我的两分钱。
https://stackoverflow.com/questions/7571147
复制相似问题
腾讯云开发者
