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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
