From owner-freebsd-current Sun Mar 26 22: 8: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4199037BE31 for ; Sun, 26 Mar 2000 22:07:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA36169; Sun, 26 Mar 2000 22:07:57 -0800 (PST) (envelope-from dillon) Date: Sun, 26 Mar 2000 22:07:57 -0800 (PST) From: Matthew Dillon Message-Id: <200003270607.WAA36169@apollo.backplane.com> To: Daniel Eischen Cc: nms@otdel-1.org, freebsd-current@FreeBSD.ORG Subject: Re: Is there spinlocks/semaphores available for drivers? References: <200003262108.QAA12802@pcnet1.pcnet.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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. 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message