Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!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: <1848@tuvie>
Date: 21 Sep 90 15:33:44 GMT
References: <12682@cs.utexas.edu> <1844@tuvie> <12712@cs.utexas.edu>
Sender: news@tuvie
Lines: 114

rhwang@cs.utexas.edu (Rwo-Hsi Wang) writes:

>
> [my original comments deleted]
>
>
>One quick way to satisfy some of the above requirements is to remove the
>related constructs, e.g., semaphores, rendezvous, delay, goto, from an
>existing language.  However, whether the resulted language is functionally
>sufficient for hard real-time applications becomes the problem.  If it is
>not, then what primitives should be provided for rectification?

Good suggestion and good question :-) !

What is needed in a hard real-time language ?

	o Means to communicate with the environment.
	o Means to communicate with other tasks, possibly in a distributed
	  computing system.
	o Access to a notion of `time'.

On the other hand a construct can only be permissible if its execution time 
is bounded. For communication message passing seems to be a reasonable option,
because the execution time of a message-send/message receive is not 
dependent on the state of other tasks in the system. 
There also is the possibility of associating
synchronization constructs (if one insists on having them) with timeouts.
However, this raises two problems:

	o A problem of the kind `this task misses it's deadline in 10%
	  percent of the cases' is transformed into one of the kind
	  `this task always meets its deadline, but does not compute 
	  a useful result in 10% of the cases'.

	o If fault-tolerance dictates redundant execution of tasks
	  the one execution may complete `just in time' while the other
	  overruns and the exception handler is called. This may
	  present problems for the decider.

Therefore, unless one uses a way to show that a set of tasks using explicit 
synchronization does meet the deadlines (see [Kli86], [Sto87] and [Lei86])
this only shifts the problem but does not solve it.

Note that the second problem must be carefully considered whenever one
bases *any* decision on the progress of time.

>Besides functional sufficiency, convenience/expressiveness may be another
>point of consideration.  For example, what will be the impact of a
>language without explicit synchronization statements and delay statements
>to distributed computing applications?

It depends on the architecture. In our experience the impact is this: 
Easier understandable, more reliable real-time programs. But then 
the architecture of our system (MARS) strongly supports communication
via messages and doing implicit synchronization via static scheduling.
For an introduction to MARS see [Kop89].


Best Regards,

Alexander Vrchoticky

--- 
References:

@article{Kligerman:TOSE86,
    author =    {E. Kligerman and A. Stoyenko},
    year =      {1986},
    journal =   TOSE,
    month =     {Sep.},
    number =    {9},
    pages =     {941-949},
    title =     {Real-Time Euclid: A Language for Reliable Real-Time Systems},
    volume =    {SE-12}
}

@book{Stoyenko:Diss,
        author =        {A. Stoyenko},
        title =         {A Real-Time Language With A Schedulability Analyzer},
        address =       {Computer Systems Research Institute, 
			University of Toronto},
        publisher =     {Dissertation},
        month =         {Dec.},
        year =          {1987}
}

@article{Leinbaugh:TOSE86,
    author =        {D. W. Leinbaugh and M.-R. Yamini},
    year =          {1986},
    journal =       TOSE,
    month =         {Dec.},
    number =        {12},
    pages =         {},
    volume =        {SE-12},
    title =         {Guaranteed Response Times in a Distributed
                    Hard-Real-Time Environment}
}

@article{Kopetz:MICRO89,
        author =        {H. Kopetz and A. Damm and Ch. Koza and M. Mulazzani
                         and W. Schwabl and Ch. Senft and R. Zainlinger},
        title =         {Distributed Fault-Tolerant Real-Time Systems:
			    The {MARS} {A}pproach},
        journal =       {IEEE Micro}
        volume =        {9},
        number =        {1},
        year =          {1989},
        month =         {Feb.},
        pages =         {25-40}
}
--
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'!)