On Thu, 12 Nov 2009, William Allen Simpson wrote:>> In recent weeks, two different network projects erroneously> strayed down the rw_lock path. Update the Documentation> based upon comments by Eric Dumazet and Paul E. McKenney in> those threads.

This still retains some pretty old and bogus language. For example, that file still talks about spinlocks being "faster than a global interrupt lock", which is kind of amusing - because we've not done that global interrupt lock thing for the last ten years or so.

So I certainly agree with discouraging rwlocks - I don't think we've ever really found a situation where they are useful except for some really special cases - but I suspect the thing needs a bigger overhaul.

I also suspect somebody should actually take a look at our _users_ of rwlocks. We have a few fairly central ones like 'tasklist_lock', and it may be an example of a _good_ case of rwlocks, but for a very non-obvious reason.

In the case of 'tasklist_lock', the magic subtle reason that makes it a good idea is that that lock is commonly taken for reading in _interrupts_. And the way rwlocks are defined, that means that you can take it for reading without doing the *_irq() or *_irqsave() versions, because rwlocks are not fair, so an active reader will never block a new reader even if there is a blocked writer pending.

So for tasklist_lock, raw rwlocks are still slower than raw spinlocks, but because of the rwlock semantics the common case doesn't need to disable and enable interrupts, so for the common case the comparison is not "raw rwlock vs raw spinlock", but "raw rwlock vs interrupt-disabling spinlock", and then it turns out rwlocks tend to win again.

(Of course, lock_write() needs to disable interrupts for tasklist_lock, but that tends to be the uncommon case).