From owner-freebsd-arch Mon Sep 25 1:28:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 1E1DF37B424; Mon, 25 Sep 2000 01:28:34 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id BAA05586; Mon, 25 Sep 2000 01:26:56 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAARlaOZk; Mon Sep 25 01:26:46 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA12659; Mon, 25 Sep 2000 01:27:56 -0700 (MST) From: Terry Lambert Message-Id: <200009250827.BAA12659@usr02.primenet.com> Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files To: mjacob@feral.com Date: Mon, 25 Sep 2000 08:27:55 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), brian@Awfulhak.org (Brian Somers), grog@wantadilla.lemis.com (Greg Lehey), cp@bsdi.com (Chuck Paterson), archie@whistle.com (Archie Cobbs), joerg@cs.waikato.ac.nz (Joerg Micheel), frank@exit.com (Frank Mayhar), jhb@pike.osd.bsdi.com (John Baldwin), markm@FreeBSD.ORG (Mark Murray), FreeBSD-arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Sep 24, 2000 08:38:56 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is easy: mark them non-reentrant. You can either acquire a > > mutex on descent into them and release it on exit/sleep, or (and > > this is better), have a per-module mutex that's acquired on the > > descent/wakeup and released on the ascent, if the flag is present. > > This will let the modules be corrected on a per FS and per CAM > > driver basis, while maintaining legacy compatability. We do not > > need another ethnic clensing of the drivers, such as what we went > > through when CAM went in, or when the X.25 and ISODE stuff was > > murdered. > > Hmm, but I sure don't want the pain of the 'unsafe_driver' mutex that Sun went > thru. Still- your point has a lot of maerit. One of the best things that UnixWare had going for it was the ability to continue using legacy drivers, file systems, and streams stacks, while those components that were reentrant were capable of giving better performance. UnixWare on a UP box was capable of 30% better performance, even after all of the SMP overhead, simply because the system was mostly reentrant (this with the terrible hit that the network stack took trying to use ODI drivers). I think that no matter how you slice it, it has to be possible for something to be done right, and to tell the difference between those things that are and aren't reentrant, easily and unequivocally. With the suggested mutex recursion (please -- use a counting semaphore, not a mutex, if you are going to permit recursion!), the only way would be to instrument the mutex acquisition macro to whine to the console any time the count increments after it reaches a value of 1. If you are willing to whine about recursion, then I suppose that having recursion would not be that bad; but turn off the whining, and there's little incentive to fix it, since to many people's minds, it won't be broken. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message