Subject: Re: interrupts, threads, and preventing wakeup-before-sleep?
To: Nathan J. Williams <>
From: None <>
List: tech-kern
Date: 02/17/2003 23:32:33
On Mon, Feb 17, 2003 at 10:31:46PM -0500, Nathan J. Williams wrote:
> 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
> another.

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                      

Seen on bottom of IBM part number 1887724: