>>> 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_.
>>
>> 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 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.
>> 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.
>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.
-
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/