From owner-freebsd-current Wed Nov 14 13:30:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1499037B417; Wed, 14 Nov 2001 13:30:26 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fAELUPP91887; Wed, 14 Nov 2001 13:30:25 -0800 (PST) (envelope-from dillon) Date: Wed, 14 Nov 2001 13:30:25 -0800 (PST) From: Matthew Dillon Message-Id: <200111142130.fAELUPP91887@apollo.backplane.com> To: John Baldwin Cc: current@FreeBSD.ORG, David Wolfskill Subject: Re: RE: lock order reversal for today's -CURRENT References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :>: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 <>< 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 <>< 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message