Can you also finally
- separate out the fastpaths more clearly. The slowpaths should not be
even visible in the I$ footprint. The fastpaths are probably better off
as a separate "fastpath.S" file to make sure that the compiler doesn't
inline the slowpath or do other insane things.
If the fastpath isn't just a few instructions, there's something wrong.
It should be written in assembly, so that it's very clear what the
fastpath is. Because most of the time, the fastpath is all that really
matters (at least as long as there is some reasonable slow-path and
contention behaviour - the slowpath matters int hat it shouldn't ever
be a _problem_).
- don't call these "fair". They may be fairER than the regular rwlocks,
but you'd really need to explain that, and true fairness you (a) can't
really get without explicit queueing and (b) probably don't even want,
because the only starvation people tend to worry about is reader vs
writer, and writer-writer fairness tends to be unimportant. So it's not
that people want the (expensive) "fairness" it's really that they want
something _reasonably_ fair considering the normal worries.
(ie if you have so much write activity that you get into write-write
fairness worries, you shouldn't be using a rwlock to begin with, so
that level of fairness is simply not very interesting).
People react emotionally and too strongly to to words like "fairness"
or "freedom". Different people have different ideas on what they mean,
and take them to pointless extremes. So just don't use the words, they
just detract from the real issue.
Also, the performance numbers on their own are pretty irrelevant, since
there's nothing to compare them to. It would be much more relevant if you
had a "this is what the standard rwlock" does as a comparison for each
number.
Linus
--
