On Mon, Sep 11, 2000 at 05:28:09AM +0200, Thorbjörn Jemander wrote:
> Hi!
> 
> I'm new to NetBSD, so pardon my ignorance. I'm not
> sure this question really fits this list; if not, please
> tell me the right forum.
> 
> Anyway, I have two questions. Pointers or references
> will do as answers:
> 
> 1. How does NetBSD schedule threads with different
> priorities? Is there any (soft) 'real-time level' as in
> e.g. BeOS? If not, is there some legal way for a thread
> to run uniterrupted for a 'longer' period of time (i.e. longer
> than the scheduler time quanta)?

You mean, in kernel or userland ? The kernel isn't preemptive yet, so
once you're in kernel you run until you return from syscall or you call
tlseep(), or a highter priority interrupt occurs.
For userland, it's just the standart unix priority, see nice, renice, etc ...
In fact you want something that could hold scheculing for some time.
There isn't any mechanism for this in the NetBSD kernel but it should'nt be
hard to add one.

> 
> 2. Can the kernel reschedule immediately on the release of
> a semaphore (released in a kernel driver)? What kind of latency
> would you expect between the release and the start of the
> execution of the thread? (On, say, a pretty standard x86
> system, ms or us?)

I guess you'll use something like tsleep() for this. When the thread
is waken up, it'll be put back on a run queue. I guess you'll call
wakeup() from an interrupt handler; in this case the interrupt handler runs
to completion. On the return from interrupt, the kernel processes
pending interrupts and they goes back to processes. At this point I'm not sure
if the process running before the interrupt runs again until its time quantun
expires, or if a new one can get scheduled. Even in the second case a
highter-priority thread could run before yours, so you can expect a 1/hz
latency here (unless you arrange for your thread to be the only one at
higth priority).

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--