From owner-freebsd-smp Thu Dec 5 12:21:40 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA01213 for smp-outgoing; Thu, 5 Dec 1996 12:21:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA01206 for ; Thu, 5 Dec 1996 12:21:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA19785; Thu, 5 Dec 1996 13:01:18 -0700 From: Terry Lambert Message-Id: <199612052001.NAA19785@phaeton.artisoft.com> Subject: Re: make locking more generic? To: smp@csn.net (Steve Passe) Date: Thu, 5 Dec 1996 13:01:17 -0700 (MST) Cc: terry@lambert.org, ccsanady@friley216.res.iastate.edu, peter@spinner.dialix.com, smp@freebsd.org In-Reply-To: <199612051940.MAA14434@clem.systemsix.com> from "Steve Passe" at Dec 5, 96 12:40:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >If CPU 1 is servicing INT 12 from a disk controller, and you get INT 4 > >from a serial port, don't you *want* CPU 2 to service the INT 4 in > >parallel??? > > yes, you do. but the problem is that CPU 1 holds the lock, so if CPU2 > tries to service INT 4, it starts spinning in the un-obtainable lock till CPU1 > finishes servicing INT 12. At this point CPU1 releases the lock, CPU2 > finally gets it and can proceed to service INT 4. Might as well let CPU2 > alone to do whatever it is doing instead. If the INT 4 is of higher priority > than INT 12, CPU1 could start servicing it immediatly. > > The proper form of fine-grainularity could eliminate this problem. Ah. I see. We are still talking about the global kernel entrancy lock in this case. Never mind then (the global entrancy lock is bogus). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.