Re: Ada OS Kernel features

["Brian Catlin" <briancatlin@mindspring.com>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:Khql7.4732$4z.14760@www.newsranger.com...
> In article <9n4euv$t9m$1@slb6.atl.mindspring.net>, Brian Catlin says...
> >Scheduler:
> >  I think that the kernel should support three types of tasks: isochronous,
> >real-time, and general purpose.  An isochronous task is a periodic
time-driven
> >task with performance requirements for bounded latency and jitter, and
> >guaranteed throughput.  A real-time task has performance requirements for low
> >latency and high throughput.  Both isochronous and real-time tasks have
bounded
> >execution times, so that the system can bound latency and jitter for other
such
> >tasks.  In contrast, a general purpose task is characterized by lengthy or
>
> Interesting. I've never seen them broken out that way. Is that a typical way
of
> thinking about real-time tasks these days? In fact, I have trouble finding
good
> references for dealing with RT tasks that have jitter requirements. As near as
I
> can tell, any such task has to be scheduled in such a way that it is the first
> task to get run after its designated clock tick. Obviously this means you
can't
> create a whole lot of these...

An isochronously scheduled task means that the task will get a fixed amount of
CPU time over time (think of it as getting a fixed percentage of the CPU over
time).  Supporting isochronous tasks is a requirement if you want to be able to
handle streaming multimedia, such as audio or video.  A simple way to implement
this, would have the scheduler use a weighted round robin scheme for scheduling
real-time and general purpose tasks. Isochronous tasks would be driven off timer
interrupts.  The kernel would assign a scheduling flag and a weight to each
real-time task. To schedule realtime tasks, the would scheduler poll a set of
flags, each of which indicates a pending task.  For each flag that is set, the
scheduler would invoke the corresponding real-time task, with the assigned
weight as a parameter.  A scheduling flag may be set by an interrupt service
routine as well as any realtime or general purpose task in the system.

 As a further refinement, the kernel could introduce the notion of preemption
windows.  Isochronous and real-time tasks can only be preempted during their
preemption windows. An isochronous task could be preempted by higher priority
isochronous tasks; real-time tasks could be preempted by isochronous tasks.
Preemption windows would be placed at the completion of a unit of work, where
little state needs to be saved in context-switching to the new task.

 A real-time task would be expected to process at most the number of work units
equal to the weight passed to it as a parameter. Upon completion, the task saves
its state, if necessary, and voluntarily returns to the scheduler.

 After having completed one round of polling for real-time tasks, the scheduler
would switch to the list of general purpose tasks. This task runs until it
blocks or the quantum timer expires. If the timer expires, the scheduler saves
the tasks's context and goes back to servicing real-time tasks.

> >be the most natural.  The layering of device drivers (as implemented) in NT
> >would also seem to be a very valuable feature.
>
> I've started to look at NT drivers recently. I do think thier layered approach
> is a cool idea, but I have one major problem with it. There doesn't appear to
be
> any good reason to require any but the lowest-level driver to run in kernel
mode
> (ring 3, supervisor, whatever you call it...) Such programs are much tougher
to
> debug, and bugs in them are much more catastrophic. It appears that they are
> just having them run in kernel mode because that's what device drivers are
> supposed to do.

Yes, it makes them more difficult to debug, but placing the drivers in the
kernel has several benefits:
1. Processing an I/O request requires access to privileged system routines and
data structures.  Allowing access to these resources from user-mode is a *BAD*
idea (this is one of the major reasons why Win98 was so unstable; applications
could step all over the kernel)
2. Putting drivers in user-mode means increasing the number of transitions
between user-mode and kernel-mode, which is *VERY* time-consuming
3. A driver will need access to the requesting process' address space, but if
the "driver" is running as part of another process, the requesting process'
address space is inaccessible.

 -Brian