Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!tuvie!vmars!alex
From: alex@vmars.tuwien.ac.at (Alexander Vrchoticky)
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Message-ID: <1853@tuvie>
Date: 25 Sep 90 08:52:26 GMT
References: <12682@cs.utexas.edu> <1844@tuvie> <224@srchtec.UUCP>
Sender: news@tuvie
Lines: 69

johnb@srchtec.UUCP (John T. Baldwin) writes:

>Does this also preclude the following:

>   1. Event "reenter-retro-burn" tied to task "calc-execute-reenter".
>   2. Hard-schedule: reenter-retro-burn at 16:30:00.5 GMT.

>If so, why?

It precludes everything for which you can not give a-priori guarantees 
that the system will meet its timing constraints under all foreseeable 
circumstances and no more. This is what hard real-time systems are for.
If you can give response time bounds for *all* tasks in the system
even when using such constructs then great. But I think it will be difficult.
As the state of the art advances more and more general constructs may
become permissible.
The point is not to disallow useful constructs but to discourage the use
of unnecessarily complex (and hence hard-to-verify) ones.


>av>	o  Unbounded loops and recursions.
>While I can certainly fathom the reason this would be desirable, how can
>it be (practically) enforced so as not to grossly interfere with the
>primary goal: getting the system to run in the first place?

Hmmm ... but the system does not only have to run in the first place, 
but also in the second, the third and in all places after that :-) 
Seriously: Calculating execution time bounds for turing machines is
pretty difficult (mail me if you have a solution :-). 
If you want to do a-priory calculation of bounds for the execution time
you *have* to place some restrictions on the programs, whether enforced 
by the programming language or by some coding standard. 
The alternative (timing verification by testing) is more expensive 
and less reliable, albeit much more often used.

>To broaden the horizon of this particular discussion thread: stochastic
>behavior of some tasks in the system can really be a pain, and cause
>all sorts of heartache (and heartburn! :-)) for the real-time practitioner,
>but it is also a fact of life.  Some algorithms simply don't have a *known*
>alternative having deterministic execution time.  We *sure* don't want to
>pad out the nondeterministic ones out to their worst case!  :) :) :)

But then you have to live with the fact that your system will fail from time
to time. I am sure that there are lots of applications where you can live with
this, but there *are* applications where you don't want to ....

`Hey, ground control, the A* algorithm in the active control system 
 for the control surfaces is just digging through the 537th level 
 of the search tree. What are we ... (silence)'

There is a tradeoff between the power and the predictability of algorithms.
For hard real-time systems, where a timing failure can lead to a catastrophe
and endanger human lives I will always argue towards the deterministic
predictable approaches.
After all the heartburn of the programmer is less of a problem than the 
burns and deaths of people in an airplane.

>John T. Baldwin                      |  johnb%srchtec.uucp@mathcs.emory.edu
>Search Technology, Inc.              | 
>                                     | "... I had an infinite loop,
>My opinions; not my employers'.      |  but it was only for a little while..."
					
				 	 So *this* is the algorithm
					 you talk about ? ;-)

--
Alexander Vrchoticky  Technical University Vienna, Dept. for Real-Time Systems
Voice:  +43/222/58801-8168   Fax: +43/222/569149
e-mail: alex@vmars.tuwien.ac.at or vmars!alex@relay.eu.net  (Don't use 'r'!)