title: Do lock-free algorithms really perform better than their lock-full counterparts?
body: <p><a href="http://blogs.msdn.com/b/oldnewthing/">Raymond Chen</a> has been doing a <a href="http://blogs.msdn.com/b/oldnewthing/archive/2011/04/15/10154245.aspx">huge</a> <a href="http://blogs.msdn.com/b/oldnewthing/archive/2011/04/14/10153633.aspx">series</a> <a href="http://blogs.msdn.com/b/oldnewthing/archive/2011/04/13/10152929.aspx">on</a> <a href="http://blogs.msdn.com/b/oldnewthing/archive/2011/04/12/10152296.aspx">lockfree</a> <a href="http://blogs.msdn.com/b/oldnewthing/archive/2011/04/08/10151159.aspx">algorithms</a>. Beyond the simple cases of the <code>InterlockedXxx</code> functions, it seems like the prevailing pattern with all of these is that they <em>implement their own locks</em>. 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"?</p>
  
  <p>I'm curious -- are there <strong>benchmarks</strong> available which show lock free algorithms to have an edge over their lock-full counterparts?</p>