Subject: Re: interrupts, threads, and preventing wakeup-before-sleep?
To: Nathan J. Williams <email@example.com>
From: None <firstname.lastname@example.org>
Date: 02/17/2003 23:32:33
On Mon, Feb 17, 2003 at 10:31:46PM -0500, Nathan J. Williams wrote:
> email@example.com writes:
> > Now, ltsleep() is not documented as doing anything to the interrupt mask.
> > So if the proper spl call is made before locking a simple lock and the
> > lock is used with ltsleep() then the spl level will not be lowered! This
> > makes simple locks useless when trying to prevent a wakeup-before-sleep
> > condition where the waker is an interrupt, and therefore makes ltsleep()
> > useless in this case.
> ltsleep() saves the spl level it is called with and restores it *for
> that lwp*. The spl will be lowered if the next lwp that runs isn't at
> an elevated spl, such as a lwp that is about to run in userlevel.
Ah, nice. Who wants to submit the update to the docs?
> In the non-MP case, you are right that the simple_lock/simple_unlock
> calls are no-ops; the mutual exclusion between the upper half and
> lower half is provided by the spl calls.
> In the MP case, the spl calls provide the same mutual exclusion as in
> the UP case, and also prevent deadlock on one processor
> (consider what would happen if the upper half got the lock and then
> the interrupt came in and started spinning, at interrupt level, for
> the same lock). The simple_lock calls provide mutual exclusion between
> one half running on one processor and the other half running on
So, when might an lwp get rescheduled? As in, how can a simple lock
be used with ltsleep() to prevent an lwp from racing with another
lwp? splsched()? How does that mix with splnet() or spltty()?
Yes, I want to keep both interrupts and other lwps from striking
during the critical section.
Thanks for the help!
Kevin P. Neal http://www.pobox.com/~kpn/
Seen on bottom of IBM part number 1887724:
DO NOT EXPOSE MOUSE PAD TO DIRECT SUNLIGHT FOR EXTENDED PERIODS OF TIME.