> kwrohrer@ce.mediaone.net writes:
> > And lo, Albert D. Cahalan saith unto me:
> >> Olaf Titz writes:
>
> >>> A problem is "hard realtime" if time constraints are involved in the
> >>> specification of the problem such that, when the time constraint is
> >>> not met, the behaviour of the program is seen as _not correct_.
To verify Olaf and I are on the same page: when you say "the behaviour is
_not correct_", it implies not only that "this particular job has failed"
but that "the system is not meeting its stated design criteria", correct?
> >> This distinction is not useful then, since the success of a hard
> >> real-time process may be far less important than the on-time
> >> behavior of a soft real-time process.
> >
> > Not useful to you, perhaps. However, it is at least a design decision,
> > and in fact has implementation consequences: hard realtime avoids all
> > possibility of missing deadlines, whereas soft realtime avoids missing
> > deadlines where possible
>
> You think soft real-time _doesn't_ avoid all possibility of missing
> deadlines? Of course not! In both cases, the OS must avoid all
> possibility of missing deadlines. In both cases, the system could
> fail due to bugs, hardware, or PC architecture.
And a mission-critical control system can be destroyed by a car bomb
conveniently going off thirty feet away. External failure is not
interesting as a scheduler design problem. Bugs mean the system is
incorrectly implemented, and an incorrectly implemented system will not
meet its design goals (at least in the corner cases). These have nothing
to do with the general scheduling problems addressed by the hard vs. soft
distinction.
> > and attempts to handle failures when deadlines are missed.
>
> That could matter a tiny bit: send signal 9 to a failed hard
> real-time process, since nothing matters anymore. Whoopie.
Wrong wrong wrong wrong wrong wrong wrong. You do not fail hard RT tasks.
Nothing else matters in a _correct_ hard RT scheduler (or at least,
nothing else is allowed to matter until this is satisfied). In a soft RT
system, you are allowed to optimise other things (f.e. throughput, or
maybe just getting less-than-abysmal CPU utilization) at the potential
cost of missing deadlines.
> >> It is only the consequences that matter, and the OS can not
> >> determine how expensive the consequences are. Humans let
> >> the OS know, and the OS must avoid missing deadlines.
> >
> > Humans must *make* the OS avoid missing deadlines, if they are
> > designing the OS or the system.
>
> Yes, for both hard and soft real-time. Would you want a soft
> real-time system that missed deadlines? I sure wouldn't.
You may prefer a few missed deadlines to having a long-running background
process starve. You may prefer to get higher CPU utilization than a hard
real-time scheduling algorithm allows. You may want to allow more
processes into the system than a hard RT admission-control algorithm will
allow.
Hard RT : make all your deadlines. All else is secondary.
Soft RT : minimize the number of missed deadlines while attempting to
increase other metrics or properties of interest.
> >From the definition given, "soft" vs. "hard" is an acedemic distinction
> that doesn't matter at all for system design. It is really _not_ OK to
> have soft real-time processes missing deadlines.
This is not an aademic distinction. In one there is an invariant. In the
other it's just something to optimize.
Adam
-- You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu No signs you see do you believe \\Boston University Computer Science And all your words just twist and turn\\ Grad Student and Linux Hacker Reviving just to crash and burn \\ <>< ---------> Why can't you listen as love screams everywhere? <--------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/