Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!brendan
From: brendan@batserver.cs.uq.oz.au (Brendan Mahony)
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Message-ID: <4956@uqcspe.cs.uq.oz.au>
Date: 21 Sep 90 00:39:01 GMT
References: <12682@cs.utexas.edu> <1844@tuvie>
Sender: news@uqcspe.cs.uq.oz.au
Reply-To: brendan@batserver.cs.uq.oz.au
Lines: 35

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  `delay' statements.
>	o  Explicit scheduling statements (of the `at 16:30 start foo' type).

I'd certainly like to know why these should not be allowed. By delay do
you mean explicitly relinquishing control of the processor? I can see
problems with scheduling statements if care is not taken to ensure that
there are no conflicts over the processor resource. Please tell us more
about the problems.


>I strongly believe that for hard real-time systems an integrated
>approach encompassing:

>	1.  Architecture
>	2.  Operating system
>	3.  Scheduling strategy 
>	4.  Programming language 

       -1.  Process model
	0.  Specification language

I really don't see how you can get a good formal description of 1-4
without doing some work on these first.
--
Brendan Mahony                   | brendan@batserver.cs.uq.oz       
Department of Computer Science   | heretic: someone who disgrees with you
University of Queensland         | about something neither of you knows
Australia                        | anything about.