From owner-freebsd-current Mon Mar 27 4:40:39 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 6634C37BA9F for ; Mon, 27 Mar 2000 04:40:28 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA18515; Mon, 27 Mar 2000 07:40:12 -0500 (EST) Date: Mon, 27 Mar 2000 07:40:11 -0500 (EST) From: Daniel Eischen To: Matthew Dillon Cc: nms@otdel-1.org, freebsd-current@FreeBSD.ORG Subject: Re: Is there spinlocks/semaphores available for drivers? In-Reply-To: <200003270607.WAA36169@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 26 Mar 2000, Matthew Dillon wrote: > :> 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 > > I don't think it would matter. A process sitting in the kernel is > *not* preempted except when being interrupted, so there are no > 'priorities', per say. Or, rather, the relative priority is strictly > that the interrupt takes priority over supervisor code except when > disabled by said supervisor code. But locks with owners wouldn't have to disable interrupts (given that we have interrupt threads). What about shared interrupts? You could still field and process the interrupt as long as it was for a different device. > In general the best solution is to avoid using locks entirely whenever > possible, and masking the interrupt for things that wind up being too > complex. For example, using fixed-length FIFOs rather then linked lists. > The writer manipulates the write index variable, the reader manipulates > the read index variable. No locking is required between reader and > writer. No argument here. Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message