eachus@MITRE-BEDFORD.ARPA (01/28/88)
I had hoped that this boogy man had been laid to rest. But some
people in the waiver community still use this argument as an attempted
justification for not using Ada. These words were not put there to
allow implementors to impose unreasonable delays.
The intention of this paragraph {9.6(1)} is to insure that
implementations are not allowed to terminate a delay before the delay
expires. Other rules (and some latitude allowed to an implementation)
determine when a task resumes execution.
When the delayed task become eligible to run, if its priority is
higher than some task that is executing, then paragraph 9.8(4)
requires that a lower priority task be preempted. It does not require
that the higher priority task execute, since an interrupt could occur
or another high priority task could become eligible to run during the
task switching process. The rules also allow for multiprocessor
implementations, and the phrase "...could sensibly be executed
using..." is to allow for distributed and heterogenous processor
systems. Paragraph 9.8(5) deals with the cases where the running and
newly eligible tasks have the same priority, or one or both tasks do
not have defined priorities, and specifies that a rendezvous is
executed at the higher of the priorities of the tasks involved.
The intent of all this was to require preemtive scheduling.
Since the rules intentionally do not specify what happens when two
tasks of equal priority are eligible to run, or the delay statement
can occur in a low priority task, it is expected that there will be
times when a task is delayed for longer than the specified delay.
(There is also another tricky little case which implementations are
starting to get right. Due to granularity of representation it is
necessary to add one tick to the computed delay.)
The rules do allow implementations to restrict the range of the
subtype priority and implement some other form of scheduler. If the
actual hardware does not provide a clock, an Ada implementation could
be validated where all tasks have the same priority, and the effect of
a delay statement is to suspend the task indefinitely. (I can just
imagine the message "Please signal when three miniutes have elapsed."
appearing on the user's terminal.) It would, of course, be
inappropriate to choose such hardware for a system which required
timed delays.
Where operating systems (read Unix and MS-DOS) suspend the
executing process while waiting for input from the terminal, a valid
implementation of the Ada IO packages will create a separate process
to do this waiting. The ACVC tests do not currently test for this,
but that does not make such an implementation valid. There is always
the possibility of an AI-325 argument for some hardware or operating
system, but for MS-DOS and Unix, I know it is possible to do it right.
Robert I. Eachus