Date: Sun, 26 Mar 2000 22:07:57 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Daniel Eischen <eischen@vigrid.com> Cc: nms@otdel-1.org, freebsd-current@FreeBSD.ORG Subject: Re: Is there spinlocks/semaphores available for drivers? Message-ID: <200003270607.WAA36169@apollo.backplane.com> References: <200003262108.QAA12802@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
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?200003270607.WAA36169>