http://tinyurl.com/pzpyvb9上的无锁堆栈的性能数据是否真实？

Question

在http://blog.memsql.com/common-pitfalls-in-writing-lock-free-algorithms/结束时，David Stolp显示了一个无锁堆栈的性能数据，表明即使争用增加，lockfree版本也比受互斥锁保护的顺序版本慢。结果很有意思，但有两件事关系到我：

• 充其量，“整体吞吐量”会降低，然后随着线程数量的增加而趋于平稳。随着线程数量的增加，整体吞吐量不应该增加吗？
• 在最终图表中，1个线程的性能值范围从大约35M到55M。对于1个线程来说，这似乎是一个非常广泛的范围（不存在任何争用）。

我试图找到一种方法来联系作者关于这些问题，但我没有成功，所以我转向SO社区，看看结果是否真实。他们呢？

Answer 1

  

充其量，“整体吞吐量”会降低，然后逐渐趋于平稳   线程数增加。不应该整体吞吐量增加   线程数增加了吗？

这是正常的！堆栈只有一个！瓶颈是线程之间的内存同步，而不是代码执行。因此，如果更多的线程填满堆栈，那么更多的内存冲突应该出现（竞争条件出现），因此吞吐量会降低。

  

在最终图表中，1个线程的性能值范围从   约35M至55M。对于1个线程来说，这似乎是一个非常广泛的范围   （不存在任何争用的地方）。

这个测试代码是不现实的，因为它只是弹出并将节点推入堆栈。因此，相对较短的代码的最小差异会极大地影响吞吐量。

如果你检查代码，你可以看到SpinLock版本非常简单并且比LockFree更快，因为它是用test_and_set原子函数制作的，它比原子CAS快得多（比较和在LockFree版本中使用的swap。

修改

在LockFree版本中使用cmpxchg16b这是16字节CAS在SpinLock只使用8字节test_and_set函数（用cmpxchg8b实现）所以存在速度差异！

Answer 2

  

充其量，“整体吞吐量”会降低，然后随着线程数量的增加而趋于平稳。随着线程数量的增加，整体吞吐量不应该增加吗？

不一定，绝对不是这种情况。如果执行的线程可以并发运行，则多线程是有益的。如果线程永远不能并发运行，或者几乎所有执行都涉及争用单个资源，那么最好使应用程序成为单线程。

此测试旨在使线程无法同时运行。几乎所有代码都争用单个资源，即堆栈。这里有意使用这个名义上不好的设计，以便测试各种并发执行方案的开销费用，并测试各种方案处理争用的程度。

  

在最终图表中，1个线程的性能值范围从大约35M到55M。对于1个线程来说，这似乎是一个非常广泛的范围（不存在任何争用）。

即使没有争用，锁定和解锁互斥锁也会涉及很多开销。比较和交换的开销要少得多，测试和设置的开销也更少。当只有一个执行线程时，正在测试的是纯粹的开销。