From owner-freebsd-current Sun Mar 26 13: 9:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CD23C37B77E for ; Sun, 26 Mar 2000 13:09:17 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA12802; Sun, 26 Mar 2000 16:08:58 -0500 (EST) Date: Sun, 26 Mar 2000 16:08:58 -0500 (EST) From: Daniel Eischen Message-Id: <200003262108.QAA12802@pcnet1.pcnet.com> To: dillon@apollo.backplane.com, nms@otdel-1.org Subject: Re: Is there spinlocks/semaphores available for drivers? Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > The answer is.... nobody knows yet :-). > > Interrupts will probably wind up running each in its own thread, and > we will probably adopt the BSDI hybridized model (which runs an interrupt > synchronously if possible and spools it to a thread otherwise) to > increase efficiency. > > I outlined a way to keep the current spl/cpl mechanisms intact while > at the same time moving interrupts to a threading model in my SMP > document: > > http://www.backplane.com/FreeBSD4/ > http://www.backplane.com/FreeBSD4/smp-api.html > > The mechanism I outline will allow interrupt execution concurrent > with supervisor execution, and allow interrupt execution concurrent > with other interrupts. For example, two different ethernet interrupts > could be taken concurrently with only minor spinlock controls > on the IF queue, and both could run concurrent with the TCP stack > (outside of the spl*() protected areas of the TCP stack). I had a look at (VI) Interrupt-Disabling Spin locks. Wouldn't it be better to use priority inheritent mutexes of some sort. If an interrupt thread tries to take a mutex that is held by another lower priority thread, then the interrupt thread would lend its priority to mutex/lock holder. Interrupts would only be disabled while taking the lock and setting the owner field, then could be reenabled immediately afterwards. This would let drivers protect potentially time-consuming sections of code without blocking interrupts. I really dislike spinlocks and am afraid of priority inversion problems. Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message