From: jtk@netcom.com (Jane Valencia)
Newsgroups: comp.os.research
Subject: Re: Microkernel for Real-Time Computing
Date: 22 Nov 92 18:25:38 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp

danh@quantum.qnx.com (Dan Hildebrand) writes:

>There is nothing that inherently prevents a monolithic kernel from 
>providing deterministic realtime scheduling.

Agreed.  The problem in a UNIX kind of kernel is that your latency to
task switch is bounded by the worst-case path length from time where
your real-time process becomes runnable to the time it runs.  In classic
UNIX, this the time until the current thread either explicitly sleeps
or returns to user mode.

In V.4 (and HP/UX until 8.0) the kernel was enhanced (if you'll pardon
the term) with "preemption points" which were simply further places
in the kernel where context could be switched to a higher priority
runnable process.  By inserting these points into long code paths, better
(lower) latencies could be achieved.

The problem is that you have to consider every code path in the system,
and you basically have to keep considering them as you make enhancements
and bug fixes.  If you put a preemption point at a place where it turns
out you shouldn't (because you were using a resource but didn't have
it sufficiently mutexed/locked/etc.), you would add a bug to the system.
Speaking from my experience with HP/UX, these bugs are not necessarily
easy to find!

>> 1. What are the advantages of microkernel for real-time applications
>> over a traditional monolithic kernel, and why?
>A true microkernel ( not a 200 Kbyte "micro"-kernel ) can be roughly 
>compared to a realtime executive in terms of complexity and performance. 

Let me spell this out explicitly.  If you have some body of code which
defines the performance and latency of your system, then all other
things being equal, the smaller it is, the easier it is to understand,
modify, and maintain.  "Understanding" in this case relates to
simple functionality, as well as latency.

>I have a paper with more details if you're interested.

I'll say he does! :-)  Very good paper, worth reading time and again.

Now, a couple imponderables:

With a "true" microkernel (like QNX), you can get a pretty good
handle on latency.  What if your real-time application wants to
use the filesystem?  Or some devices?  Moving code out of the kernel
does not help you build a real-time system if you still depend on
that code, and it is not built to support real-time features.
Classic examples of this are disk sort routines which starve a
single I/O from a real-time process while taking loads of new I/O's
from background processes.  In this sense microkernels are a "divide
and conquer" technique; you still have to conquer the individual
parts.

One thing the paper on QNX I read *didn't* tell was how to handle
those memory-to-memory copies.  How do you keep handles on various
process' memory?  In what context do you do the copy?  If it's in the
kernel, how do you go about watching for higher priority events?  If
it's in the user context, how do you provide an acceptable granularity
of process protection?

					Andy Valencia
					jtk@netcom.com