Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rhwang
From: rhwang@cs.utexas.edu (Rwo-Hsi Wang)
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Message-ID: <12712@cs.utexas.edu>
Date: 20 Sep 90 20:39:39 GMT
References: <12682@cs.utexas.edu> <1844@tuvie>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 38

In article <1844@tuvie> alex@vmars.tuwien.ac.at (Alexander Vrchoticky) writes:
>To stimulate discussions I suggest that the 
>following should *not* be used for hard real-time systems: 
>
>	o  Explicit synchronization statements (semaphores, rendezvous).
>	o  `delay' statements.
>	o  Explicit scheduling statements (of the `at 16:30 start foo' type).
>	o  Unbounded loops and recursions.
>	o  Unstructured control-flow statements (goto).
>	o  Dynamic memory allocation.
>	o  Dynamic task creation and termination.

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?

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?

>I strongly believe that for hard real-time systems an integrated
>approach encompassing:
>
>	1.  Architecture
>	2.  Operating system
>	3.  Scheduling strategy 
>	4.  Programming language 

While it will be interesting to see discussions on all of the above topics,
to increase the change of achieving more constructive conclusions, I'd like
to suggest that we first focus on the programming language issue.

Rwo-Hsi Wang
rhwang@cs.utexas.edu