Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 21, 2018 3:59 pm wrote:
> Travis (travis.downs.delete@this.gmail.com) on August 21, 2018 3:18 pm wrote:
> >
> > Maybe this lets you build the "holy grain" read-write lock for ready heavy scenarios?
>
> Yes.
>
> However, I warn you: we used to have something very much like those read-write locks in the kernel
> (we still do, but we used to have them too), and they have some really really nasty behavior.
> ...
> Because it turns out that sometimes "fairness" is actually more important than absolute
> performance, because unfair locks can have worst-case scenarios that are so bad that
> even if they are faster on average, they are completely unacceptable in reality.

The unfairness that was problematic was a constant stream of readers starving out writers, or between various writers or what?

A reasonable strategy would seem to be to make such locks favor writers as far as fairness goes: once a writer expresses interest, no new readers enter the critical section. So the lock would favor writers over readers, but they are rare anyways, and this doesn't slow down the reader fast path.

Or maybe the kernel lock does something like that but the problem arises when writers are actually common and then totally starve out readers?

I'm actually well aware of the various failure modes of these things, but once you get the basics right you can usually add some more complex behavior mostly free (since it lives on the slow paths anyways) in order implement whatever fairness heuristic you want.