Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!apple!bionet!agate!saturn!masscomp!fdr@swan.ulowell.edu
From: masscomp!fdr@swan.ulowell.edu (Franklin Reynolds)
Newsgroups: comp.os.research
Subject: Re: Real Time Operating Systems
Message-ID: <5388@saturn.ucsc.edu>
Date: 3 Nov 88 23:17:16 GMT
Sender: usenet@saturn.ucsc.edu
Organization: MASSCOMP - Westford, Ma
Lines: 61
Approved: comp-os-research@jupiter.ucsc.edu


In article <5331@saturn.ucsc.edu> (Thomas V. Frauenhofer) writes:
>
>Remember, time deadlines are the raison d'etra of real-time systems.  We want
>guaranteed, repeatable performance every time.
>

I certainly agree that time constraints are the uniquely identifying
characteristic of realtime systems. However, I contend that guaranteed,
repeatable performance means different things in different situations.
If we are discussing a realtime application that controls a high performance
disk controller it is not unreasonable to believe that the system can 
designed so that all of the demands on it can be met. This is one type
of guaranteed behavior.

If we are talking about a distributed control application running 
a large factory full of robots then we have to deal with aperiodic 
and unpredictable work loads. In this case, "guaranteed, 
repeatable performance" means dealing with the overload condition in a 
guaranteed and repeatable manner. Presummably the
most important things are allowed to meet their time constrants while
the least important things are discarded.

I feel that simple, embedded systems with periodic or at least predictable
demands are fairly well understood. I am much more interested of large
distributed systems. Unfortunately most of the research seems oriented
towards the former, rather than the latter problem.

>>
>>Another thing about most real time research is that most people seem to
>>treat deadlines as all or nothing situations.
>
>Depends on what are the results of missing a deadline.  Some are fatal; some
>aren't.
>

Right. But what is lacking is a good way for the programmer to express
"soft deadlines" and the value to the system associated with them. How
does the programmer tell the scheduler that a process has residual value
even though its deadline has been missed? How does the programmer tell
the scheduler the rate at which the process loses value once it has 
missed its deadline. What if the rate it loses value is not constant?

Most (all ?) deadline scheduling systems starve the threads with soft 
deadlines regardless of the value to the system the soft deadline process.
That might sound reasonable, but what if the process with the soft
deadline acquires some resource that a hard deadline process needs? If
the soft deadline process is starved then any dependent hard deadline
processes will miss their deadlines. 

>You might want to leaf through the proceedings of the IEEE Conferences on
>Real-Time Systems.
>

I have. But usually there are only a few papers on scheduling. Not only is
the small number of papers a drag but the majority of those deal exclusively
with hard deadlines and non-overload conditions. 

Franklin Reynolds
harvard!masscomp!fdr
fdr@masscomp.uucp