Raymond Chen 一直在进行巨大 系列 上 blogs.msdn/b/oldnewthing/archive/2011/04/12/10152296.aspx>无锁 算法.除了InterlockedXxx函数的简单情况以外，似乎所有这些方法的普遍模式是它们实现自己的锁.当然，没有处理器锁，但是在每个CPU上不断循环以确保一致性的概念非常像自旋锁.作为自旋锁，它们将比操作系统随附的常规锁效率更低，因为它们在等待其他线程时不会产生对量子的控制.因此，每当有人来找我说但是我的算法是无锁的"时，我的一般回答是如此"?
Raymond Chen has been doing a huge series on lockfree algorithms. Beyond the simple cases of the InterlockedXxx functions, it seems like the prevailing pattern with all of these is that they implement their own locks. Sure, there are not processor locks, but the concept of looping over and over on each CPU to ensure consistency is very much like a spinlock. And being a spinlock, they are going to be less efficient than the general locks that come with the operating system because they do not yield control of their quanta while waiting for other threads. Therefore, whenever someone comes to me and says "but my algorithm is lock-free", my general response is "so"?
我很好奇-是否有可用的基准来显示无锁算法，使其比完全锁的算法更具优势?
I'm curious -- are there benchmarks available which show lock free algorithms to have an edge over their lock-full counterparts?
推荐答案通常，每个线程的无锁算法效率都较低-如您所提到的，要实现无锁算法，您要做的工作更多.简单的锁.
In general, lock free algorithms are less efficient per thread - you're doing more work, as you mentioned, in order to implement a lock free algorithm than a simple lock.
但是，面对竞争，它们确实可以显着提高整个算法的整体吞吐量. 线程切换延迟和上下文切换，它在多个线程上运行很快，从而极大地降低了应用程序的吞吐量.无锁算法有效地实现了它们自己的锁"，但是这样做的方式是防止或减少上下文切换的数量，这就是为什么它们倾向于不执行其对应的锁的原因.
However, they do tend to dramatically improve the overall throughput of the algorithm as a whole in the face of contention. Thread switching latency and context switches, which fast, over many threads slow down the throughput of your application dramatically. Lock free algorithms effectively are implementing their own "locks," but they do so in a manner that prevents or reduces the number of context switches, which is why they tend to out perform their locking counterparts.
话虽这么说-其中大部分取决于所讨论的算法(和实现).例如，我有一些例程可以设法切换到.NET 4的新并发集合，而不是使用以前的锁定机制，并且在我的总算法速度上测得了近30％的改进.话虽如此，与基本锁相比，您可以找到许多基准测试，这些测试使用某些相同的集合显示性能降低.与所有性能优化一样-您真的不知道，直到您 measure .
That being said - most of this depends on the algorithm (and implementation) in question. For example, I've got some routines that I managed to switch to .NET 4's new concurrent collections instead of using the previous locking mechanisms, and have measured improvements over near 30% in my total algorithm speed. That being said, there are many benchmarks you can find that show reduced performance using some of these same collections when compared to a basic lock. As with all performance optimizations - you really don't know until you measure.
更多推荐
无锁算法的性能真的比全锁算法好吗?
发布评论