News for hackers. Stuff that matters.
Re:Measuring mutexes, spinlocks and how bad the Linux schedu... by jiveturkey on Tuesday December 31, 2019 @12:20PM (#21922650)
> 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.)

Re:Measuring mutexes, spinlocks and how bad the Linux schedu... by banachtarski on Tuesday December 31, 2019 @08:46PM (#21926082)
You don't even need to read in between the lines. He literally states that in his conclusion...
Re:Measuring mutexes, spinlocks and how bad the Linux schedu... by trasz on Tuesday December 31, 2019 @03:33PM (#21924487)
And that’s precisely what most operating systems other than Linux do: use adaptive mutexes as the default mechanism, not spinlocks.
Re:Measuring mutexes, spinlocks and how bad the Linux schedu... by gpderetta on Wednesday January 01, 2020 @06:09AM (#21927596)
Pthread_mutex on linux is also an adaptive mutex, although the spinning count might not be optimal.