From owner-freebsd-hackers Thu Sep 19 06:27:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA02070 for hackers-outgoing; Thu, 19 Sep 1996 06:27:47 -0700 (PDT) Received: from firewall.mc.com (firewall.mc.com [192.148.197.15]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA02033 for ; Thu, 19 Sep 1996 06:27:41 -0700 (PDT) Received: by firewall.mc.com id AA27894 (5.65c/IDA-1.4.4 for ); Thu, 19 Sep 1996 09:27:07 -0400 Received: from jericho.mc.com(192.233.16.4) by firewall via smap (V1.3) id sma027889; Thu Sep 19 09:26:44 1996 Received: from bach (bach [192.233.16.203]) by jericho (8.6.11/8.6.11) with SMTP id JAA10374; Thu, 19 Sep 1996 09:26:43 -0400 From: "Gordon W. Ross" Received: by bach (4.1//ident-1.0) id AA03526; Thu, 19 Sep 96 09:26:42 EDT Date: Thu, 19 Sep 96 09:26:42 EDT Message-Id: <9609191326.AA03526@bach> To: michaelh@cet.co.jp Cc: freebsd-hackers@FreeBSD.ORG, tech-kern@netbsd.org In-Reply-To: (message from Michael Hancock on Thu, 19 Sep 1996 10:59:37 +0900 (JST)) Subject: Re: spl models and smp (was Re: Some interesting papers on BSD ...) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Date: Thu, 19 Sep 1996 10:59:37 +0900 (JST) > From: Michael Hancock > [Just going through some old mail] > > I was reviewing some spl and locking models for SMP. SVR4/MP combines > locking primitives with spl and Solaris is completely redesigned to the > implementation to use kernel threads instead for interrupts so it can use > the same locking model as the rest of the code. Actually, I'm pretty sure that's not quite true. Here is how it works. The relevant parts of the interface are: /* This is a mutex lock. It MIGHT lock out interrupts. */ kmutex_t driver_mutex; /* Somewhere, during initialization (attach) you do this: */ mutex_init(&driver_mutex, "mcos", MUTEX_DRIVER, (void*)&driver_ibcookie); /* Then, a section that needs atomic actions is wrapped with: */ mutex_enter(&driver_mutex); /* now have exclusive access to the object locked with this mutex. */ mutex_exit(&driver_mutex); /* now others may take the mutex lock. */ The way these block interrupts is: if the driver_ibcookie (which was returned to you when you attached your interrupt handler) is passed to mutex_init, rather than a null pointer, then anyone who does a mutex_enter() on that mutex will raise their spl as needed to block that interrupt, and then spin-wait. The spin-wait will never have to actually spin unless there is another CPU that holds the mutex. When we take the mutex from non-interrupt level, the mutex_enter() will have raised the spl() such that we don't have to worry about deadlocking against our own interrupt handler. Also note that Solaris no longer supports sleep/wakeup in MP drivers. Instead, you use these new functions: /* Here is the equivalent to the old sleep() call: */ status = cv_timedwait_sig(&sp->condvar, &driver_mutex, abst); /* Here is the equivalent to the old wakeup() call: */ cv_signal(&sp->condvar); Note that you MUST hold a mutex lock on some object that has both the mutex and a condition variable, adn the cv_timedwait_sig() does an atomic "block and release the mutex" while making you non-runnable, and later does an atomic "resume and take mutex." Interesting scheme, eh? Gordon