On Mon, Feb 17, 2003 at 10:31:46PM -0500, Nathan J. Williams wrote:
> kpneal@pobox.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
> 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                                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.