cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h

[Robert Watson]

On Tue, 1 Apr 2008, Jeff Roberson wrote:

>> I don't think this is a good thing either, but I also think that there are 
>> some cases where there just are different access orders.  I'd rather want a 
>> clean way out of this than a lot of difficult per-instance hacks.  This 
>> does not mean that these can't be fixed cleanly, but I think it's really 
>> hard sometimes especially for code we import from elsewhere (hence the 
>> personal interest).
>
> I think the best solution is to treat rlocks as wlocks in terms of access 
> orders.

The 'problem' is that there are certain usage cases for rwlocks where 99% of 
paths use only recursive read locks, with rather incestuous lock orders with 
respect to other locks, and 1% of paths use write locks and are very 
conservative about the calling path.  I'm sure the example that Max has in 
mind is pfil, where you may get pfil invocation as you enter the stack or as 
you exit it, but whose lock should not ever lead to deadlock as it's only 
acquired readable in those paths.  The key missing bit of the picture is that 
the write path must be constructed very, very carefully so that it is never 
called holding any locks that interact with the read locks.  What would be 
very nice is if witness fired if the write path got it wrong in those cases, 
since using rwlocks effectively as a reference count to prevent subsystem 
reconfiguration while in use is a structure likely to be used elsewhere.

Robert N M Watson
Computer Laboratory
University of Cambridge