> Yes, fairness was certainly made the default for reasons at some point (but still, even then, one might argue that an opt-in solution might have been better).
I think an unfair or opt-in-fair solution was deemed worse than fair-by-default for the simple reason that the most straightforward way to implement mutexes is
enter kernel mode
maybe grab a spinlock if on SMP
add yourself to the waiting list
sleep until woken up
do critical section
enter kernel mode
spinlock
wake the first waiting thread
That's a functionality every mutex must have and it happens to give fair semantics for free. Making semantics weaker for the purpose of optimization (and not just for the sake of making application developer's life harder or future flexibility which may happen to never be needed) actually takes additional work on top of that.
Since we are talking about a uniprocessor desktop OS developed in the nineties, it's plausible they didn't care about mutex performance as much as today and giving this extra guarantee afforded by their simple implementation seemed reasonable at the time.
I'd love to see them perform the same benchmark on macOS 10.12. Pthread mutexes were sped up in "the new OSes" according to a tweet made last year (sorry no link), though I'm not sure if that was referring to 10.11 or 10.12. Either way, the benchmark should perform better now, and I'm curious how much. I'd run it myself except those numbers wouldn't be comparable to OP's Mac Mini benchmark. Of course, OP's Linux benchmark numbers aren't either, because it's a different (and probably much more powerful) machine.
I think an unfair or opt-in-fair solution was deemed worse than fair-by-default for the simple reason that the most straightforward way to implement mutexes is
That's a functionality every mutex must have and it happens to give fair semantics for free. Making semantics weaker for the purpose of optimization (and not just for the sake of making application developer's life harder or future flexibility which may happen to never be needed) actually takes additional work on top of that.Since we are talking about a uniprocessor desktop OS developed in the nineties, it's plausible they didn't care about mutex performance as much as today and giving this extra guarantee afforded by their simple implementation seemed reasonable at the time.