Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!emory!stiatl!srchtec!johnb
From: johnb@srchtec.UUCP (John Baldwin)
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Message-ID: <232@srchtec.UUCP>
Date: 26 Sep 90 19:22:48 GMT
References: <1844@tuvie> <224@srchtec.UUCP> <1853@tuvie>
Organization: search technology, inc.
Lines: 89


In article <1853@tuvie> alex@vmars.tuwien.ac.at (Alexander Vrchoticky) writes:
>
>It [the suggested limits on RT primitives -jtb] 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.

When you refer to the "system" meeting its timing constraints, are you
talking about the system as a whole, or a particular task (subroutine, or
what-have-you) completing execution in <= 'n' units time?

>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.
...
>The point is not to disallow useful constructs but to discourage the use
>of unnecessarily complex (and hence hard-to-verify) ones.

Okay, we agree on this completely.

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

Indeed: it is this "doing RT by tweaking" approach which I think we
all want to avoid.  I'm not espousing a view that we place no restrictions
on the programs;  in fact, I'm not particularly arguing a point of view
at all... I'm trying to use this discussion to maximum effect in educating
myself about real-time.  (Just wanted this to be clear since I'm liable
to put foot in mouth any day now :-)).

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

I thought that one of the "charter" items of hard real-time was, in fact,
to be able to ensure that *when* your system begins to fail, it does so
in a rational, and predictable way, incrementally.

>   `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.

As I have stated before, the project I'm involved in *involves* aviation.
It also involves AI, which (inherently) means that the algorithms used
will tend towards more power and less predictability.  To get rid of
these concerns is to get rid of the project.  Instead of getting rid
of it, I want to get it on a sound RT footing.

BTW, the system doesn't directly drive the control surfaces.   :-}
(I thought you'd like to be able to sleep at night.)



>>                                     | "... 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 ? ;-)

Actually, it refers to something a co-worker said when several of us were
tired and shooting the breeze.  It suddenly occurred to me that if one
took the phrase "infinite loop" super-literally, one arrived at a very
off-kilter view of the world:

   "Well, boss, we need another machine because Larry had another
    infinite loop."

   "Another useless machine?  That's the third he's wasted in five months!"

   "Yeah.  But they make great doorstops."



-- 
John T. Baldwin                      |  johnb%srchtec.uucp@mathcs.emory.edu
Search Technology, Inc.              |  "Pereant qui ante nos nostra dixerunt!"
                                     |
Opinion (open 'nyun [noun]): knowledge without the hindrance of silly facts.