> > If you have a safeguard system to prevent a high-priority process from
> > eating the CPU, you're no longer hard real-time, unless you've got
> > some very sophisticated notion which allows the scheduler to
> > distinguish when a high-priority process is spinning its wheels
> > instead of doing useful work..

> Well, not exactly. I don't see why a hard real-time system can't
> say `nobody gets more than 80% of the CPU, ever.' It's the equivilant
> of putting a slower CPU in the machine.

A hard real-time can't say that because real-time isn't about
performance.  Real-time is about *predictable response time*, and
refusing to schedule a real-time task for some period of time just
because it has been busy means it will blow its response deadline.  To
use the example available, when a software modem is ready to transmit
the next value, the modem doesn't particularly care whether the user
running xtrek is seeing the mouse jerk around, that next value *has to
be ready on time*, because the modem on the *other* end of the link
isn't going to wait.  (The motto of one vendor of real-time executives
(I've forgotten which one) was "Right answers late are *wrong*.")

If you want to have a fancy scheduler with flexible priorities, fine,
have a fancy scheduler with flexible priorities.  Just *call* it a
fancy scheduler with flexible priorities, and not a real-time
scheduler, unless it meets the needs of real-time tasks.

Now, one way to partially protect a general-purpose system from a
broken real-time task is to have some kind of deadman timer which the
real-time task must tickle every now and then or risk getting
rescheduled (or killed).  (That will irritate real-time programmers
(unless it's optional), but at least it's the kind of response-time
constraint they're used to dealing with...)  But I'd argue that if you
really want to offer a real-time capability, you should bite the
bullet and allow a buggy real-time process to lock up the system;
that, of course, implies that real-time priorities should only be
available to superuser processes, but by and large, people who are
really interested in real-time work only have one real-time task in
mind which isn't going to be fired up on a whim by normal users.
(This software modem idea is maybe on the ragged edge of that, but if
pppd is usually run by root, why can't the modem that it talks to be
run by root?)  (And anyone who thinks they can successfully lard a
system with several independant real-time tasks without carefully
examining the interactions between those tasks is sorely mistaken.)

On the other hand, a real-time task generally needs to run without
any hardware interrupts enabled (because you can't predict how much
time you'll lose to them), so it's probably impossible to provide a
genuine "hard real-time" NetBSD anyway.

(What's my real-time experience?  Work in an operating system that
tried to provide real-time response with just a flexible scheduler,
and a careful study of the genuine real-time executives which we
were completely unable to replace with just a flexible scheduler...)