> Why isn't the conclusion to just ...

Sigh. From the article itself:

> I hope to have convinced you to avoid spinlocks, even for very short sections. Spinlocks are only a benefit if you really really care about the fast path and are certain that the lock will essentially always be free to take. On my computer the fast path on a spinlock is roughly 7ns and on a mutex it’s roughly 14ns, so both of those numbers are very fast. But when spinlocks go bad, the scheduler can be really confused, at least on Linux.

I did read it till the end but missed that bit about the fast path somehow. I struggle to see a case where you care enough about those 7ns but the Windows scheduler was a different story.

> What these benchmarks have in common is that they measure code in which there is nothing else to do except fight over the lock. In that environment the only thing that makes sense is to use a spinlock. Because if you go to sleep, all that will happen is that some other thread will wake up that will fight over the same lock.

That said, his conclusion is in fact just as you stated, if you read in between the lines. (This paper is really about the scheduler, so it's not exactly that conclusion.)

You don't even need to read in between the lines. He literally states that in his conclusion...

And that’s precisely what most operating systems other than Linux do: use adaptive mutexes as the default mechanism, not spinlocks.

Pthread_mutex on linux is also an adaptive mutex, although the spinning count might not be optimal.

No that was the conclusion: use mutexes