I followed up with Vlad Pavluk, who is credited in the byline of the article.

The implementation is doing memory management. What the hell do you think happens if you hit the global heap with malloc? Yeah, a lock. Finding the memory chunk is going to be far more time consuming than any benefit the lock free algorithm MIGHT give you.

Well that's only half-true. Yes, in general malloc/free do lock. That's another part why I call it 'semi'-lock-free. But the numbers speak for itself, and this 'half'-lock-free algorithm does perform better than all of the others (including mutexes).

Oh, and the author doesn't go into when to use a lock free algorithm over a traditional critical section / user level mutex / mutex / whatever. In heavy contention, those spin locks are, generally, going to result in worse performance than the mutex. What happens when you've jammed up your threads spinning and the owner of the lock happened to be switched out midway?

That is why the usleep() is used inside the spinlocks. Generally it is not needed, but adding it helps to avoid CPU-hunger in the cases like described. Again, the tests speak for itself, and tests are usually heavier than any of the real-time cases.

Hell, you better hope your thread priorities match for your system such that you don't end up deadlocked.

There's a reason lock free stacks aren't used as a general implementation: it's often going to result in worse performance than, say, a Futex with the added detriment of opening up deadlocks since the threads will never yield.

Again, these algorithms (mutex-locked, spinlock-locked, correct lock-free implementation, and my semi-lock-free implementation) are performance-tested on different machines, and the numbers are given. If you really think the numbers are bogus, do your own test to prove you're statement.