Path: utzoo!attcan!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: <1847@tuvie>
Date: 21 Sep 90 13:29:09 GMT
References: <12682@cs.utexas.edu> <1844@tuvie> <4956@uqcspe.cs.uq.oz.au>
Sender: news@tuvie
Lines: 56

brendan@batserver.cs.uq.oz.au (Brendan Mahony) writes:

[asks why I think that explicit scheduling statements should not be 
 used in hard real-time systems]

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

For the system's scheduler the delay statement is really 
only a special case of the `at xx:xx do yyyy' statement, 
as both require the scheduling of a specified
task at a specified point of time in the future.

The first question about delay-statements: 
How much extra delay is acceptable? If I execute
the statement `delay 10', is it permissible to continue after 11 seconds ?
If not, is it permissible to preempt another task to allow the task
in question to continue execution `exactly' after ten seconds (exactly 
meaning at the first scheduling decision after ten seconds)?

Whatever your decision is, the next question immediately pops up:
Can you analytically guarantee that the required
timing behavior is indeed met under all forseeable circumstances?
Remember that the programming language rests on a run-time system that 
has to schedule tasks according to some strategy (be it rate monotonic,
least laxity, static scheduling, ...). This scheduler has to guarantee
the timely execution of *all* tasks, not just a single one. 
The localized specification of required timing behavior via explicit
scheduling statements in single tasks is making this much more difficult
and sub-optimal solutions are the best one can hope for.

Al Mok argues in [Mok84] that decisions with global impact on the system 
(relinquishing the CPU, initiating actions at certain points in time) 
should be done with a global view of the system, 
including its scheduling strategy, not in the restricted context of a task.
[This is a recommendation :-) ]

----
References:

@inproceedings{Mok:PRTS84,
author = {A. K. Mok},
title = {The Design of Real-time Programming Systems Based on Process Models},
booktitle = {Proc. 1984 Real-Time Systems Symposium},
month = {Dec.},
year = {1984},
pages = {5-17}
}

--
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'!)