3 ms·

Why isn't the conclusion to just use the mutex at least on Linux? It seems to have both consistently low latency and great throughput. What else can you get fro

Why isn't the conclusion to just use the mutex at least on Linux? It seems to have both consistently low latency and great throughput. What else can you get from the spinlock?

jiveturkey 7y ago
> 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.)
- trasz 7y ago
  And that’s precisely what most operating systems other than Linux do: use adaptive mutexes as the default mechanism, not spinlocks.
  - gpderetta 7y ago
    Pthread_mutex on linux is also an adaptive mutex, although the spinning count might not be optimal.
- banachtarski 7y ago
  You don't even need to read in between the lines. He literally states that in his conclusion...
7532yahoogmail 7y ago
No that was the conclusion: use mutexes
banachtarski 7y ago
> 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.
- pedrocr 7y ago
  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.

Why isn't the conclusion to just use the mutex at least on Linux? It seems to have both consistently low latency and great throughput. What else can you get from the spinlock?

jiveturkey 7y ago

> 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.)

trasz 7y ago
And that’s precisely what most operating systems other than Linux do: use adaptive mutexes as the default mechanism, not spinlocks.
- gpderetta 7y ago
  Pthread_mutex on linux is also an adaptive mutex, although the spinning count might not be optimal.
banachtarski 7y ago
You don't even need to read in between the lines. He literally states that in his conclusion...

7532yahoogmail 7y ago

No that was the conclusion: use mutexes

banachtarski 7y ago

> 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.

pedrocr 7y ago
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.