Doubts with scheduler code

[Anand H. Krishnan]

Hi,


> > * First one is in the  wakeup() code. After a series of calls wakeup()
> > lands in maybe_preempt() and if preemption is enabled maybe_preempt()
> > switches to a new thread (if a high priority thread has been made runnable).
> > That means that an interrupt handler which calls wakeup() will not return
> > immediately. (I'm looking @ ULE scheduler).
> >
> > So is there a problem when wakeup() is called from high priority (fast
> interr
> > upt) handlers ?
>
> Interrupt threads have higher priority than the threads they wakeup.  For
> the INTR_FAST case we run INTR_FAST handlers inside a critical section so
> that if a INTR_FAST handler wakes up a thread such as the clock or serial
> SWI, the preemption is deferred until after the INTR_FAST handler returns.

Saw that yesterday. Thanks for the clarification...

>
> > * Second one is in spinlock code. Can anyone say why critical_enter is
> > called from spinlock_enter() ? The only thing that critical_enter seems to
> > be doing is to increment td_critnest which probably helps in finding out
> > whether a thread can be pre-empted or not. But spinlock_enter() disables
> > interrupts and I fail to understand how can any thread become runnable
> > and get scheduled in between.
>
> A thread may wake up another thread while holding a spin lock.  There are
> numerous examples of this.

Never thought about that..

>
> > I've one more..
> >
> > * msleep() allows a thread to change it's priority when it gets woken up and
> > in many places they gets woken up with very high priority indeed. Is there
> > any convincing reason as to why it should be ?
>
> This is something that the 4BSD scheduler has done since before FreeBSD
> existed.  The priority boost is intended to give higher priority to
> interactive processes (since they tend to sleep on I/O a lot) versus
> compute-bound processes.

Thanks John and Coleman for your replies.

Anand

>
> --
> John Baldwin
>