c - 如何评估无锁队列的性能？

Question

我已经使用http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf中解释的危险指针方法实现了无锁队列。使用 GCC CAS 指令来实现，并使用 pthread 本地存储来存储线程本地结构。 我现在正在尝试评估我编写的代码的性能，特别是我正在尝试将此实现与使用锁(pthread 互斥体)来保护队列的实现进行比较。
我在这里问这个问题是因为我尝试将它与“锁定”队列进行比较，我发现这相对于无锁实现具有更好的性能。我尝试的唯一测试是在 4 核 x86_64 机器上创建 4 个线程，在队列上执行 10.000.000 个随机操作，它比无锁版本快得多。

我想知道您是否可以建议我遵循一种方法，即我必须在队列上测试什么样的操作以及我可以使用什么样的工具来查看我的无锁代码在哪里浪费时间。

我还想了解无锁队列的性能是否可能会因为 4 个线程不足以看到重大改进而变得更差......

谢谢

Answer 1

第一点:无锁编程并不一定能提高速度。无锁编程(如果正确完成)可以保证前进。当您使用锁时，一个线程在持有互斥体时可能会崩溃(例如，进入无限循环)。当/如果发生这种情况时，等待该互斥体的其他线程就无法取得更多进展。如果该互斥体是正常操作的核心，那么您可能必须轻松地重新启动整个过程，然后才能完成更多工作。使用无锁编程，就不会出现这种情况。无论任何一个线程发生什么情况，其他线程都可以向前推进¹。

也就是说，是的，您希望的事情之一通常是更好的性能 - 但要看到它，您可能需要四个以上的线程。在数十到数百个线程的范围内，您的无锁代码将有更好的机会显示出比基于锁的队列更高的性能。然而，要真正做很多好事，您不仅需要更多的线程，还需要更多的核心——至少根据我到目前为止所看到的，有四个核心和编写良好的代码，这不太可能足够对无锁编程的锁的争用显示出很大的(如果有的话)性能优势。

底线:更多线程(至少几十个)将提高无锁队列显示性能优势的机会，但只有四个核心，如果基于锁的队列仍然如此，也不会太令人惊讶跟上。如果添加足够多的线程和核心，无锁版本几乎不可避免地会获胜。所需的线程和核心的确切数量很难预测，但您应该至少考虑数十个。

<小时/>

¹ 至少对于互斥锁之类的东西来说是这样。像 fork-bomb 这样消耗掉所有系统资源的东西可能会剥夺其他线程足够的资源来完成任何事情——但是对配额之类的事情的一些关注通常也可以防止这种情况发生。