From owner-freebsd-hackers Sun Jul 14 17:22:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA16815 for hackers-outgoing; Sun, 14 Jul 1996 17:22:46 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA16806 for ; Sun, 14 Jul 1996 17:22:43 -0700 (PDT) Received: from zygorthian-space-raiders.MIT.EDU (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id RAA17820 for ; Sun, 14 Jul 1996 17:22:40 -0700 Received: (from mycroft@localhost) by zygorthian-space-raiders.MIT.EDU (8.7.4/8.6.11) id UAA06423; Sun, 14 Jul 1996 20:20:51 -0400 (EDT) To: Warner Losh Cc: Michael Hancock , freebsd-hackers@freebsd.org, tech-kern@NetBSD.ORG Subject: Re: Some interesting papers on BSD ... References: <199607141837.MAA09822@rover.village.org> From: mycroft@mit.edu (Charles M. Hannum) Date: 14 Jul 1996 20:20:33 -0400 In-Reply-To: Warner Losh's message of Sun, 14 Jul 1996 12:37:48 -0600 Message-ID: Lines: 19 X-Mailer: Gnus v5.2.22/Emacs 19.30 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh writes: > > How is that different from taking out fine grain locks? At least in Dynix (as told to me by someone who works for Sequent), the spl level is raised only on the processor that took the lock. This protects an interrupt routine running on the same processor from trying to lock the same object, and thus prevents deadlocks. It also means that the locks can simply do nothing for non-SMP systems. The other relevant piece is that when an interrupt routine attempts to grab a lock that is already being held, it spin-waits until the lock is free. Some would argue that this is expensive, but with tweaking the duration that most locks are held can be made very small (certainly cheaper than any mechanism to defer the interrupt if it were allowed to run on the same CPU).