Date: Wed, 14 Nov 2001 13:30:25 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: current@FreeBSD.ORG, David Wolfskill <david@catwhisker.org> Subject: Re: RE: lock order reversal for today's -CURRENT Message-ID: <200111142130.fAELUPP91887@apollo.backplane.com> References: <XFMail.011114115716.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>:This is due to the sx worker locks not using MTX_NOWITNESS with the pool :>:mutex :>:changes. It's not a problem though. :>: :>:-- :>: :>:John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ :> :> Would it make sense for me to add a new MTX flag that disables certain :> non-applicable warnings? : :Err, that's what MTX_NOWITNESS sort of does. This one is a bit hard, as you :need a way to tell witness to ignore the lock orders between the reader writer :locks and the smaller locks used in implementing those locks. Using :MTX_NOWITNESS on the sx worker locks worked great for this. If the sx locks :had their own pool of MTX_NOWITNESS locks that would work fine. They could :share this pool with the lockmgr worker locks as well. They shouldn't be used :for anything else, however. This is why I wanted to allow for multiple pools. : :-- : :John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ I'm not against the concept of multiple pools, but I'm not really for it either. The various mutexes are already far too complex for their own good... look at SX locks, for example. The struct sx is about 8 times as big as it needs to be to implement reasonable functionality. I would scrap the upgrade and downgrade API and I would scrap the condition variables and go with a simple shared/exclusive counter. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111142130.fAELUPP91887>