Date: Mon, 27 Mar 2000 07:40:11 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: nms@otdel-1.org, freebsd-current@FreeBSD.ORG Subject: Re: Is there spinlocks/semaphores available for drivers? Message-ID: <Pine.SUN.3.91.1000327072156.16642A-100000@pcnet1.pcnet.com> In-Reply-To: <200003270607.WAA36169@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000327072156.16642A-100000>