From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!IBM.COM!NCOHEN
From: NCOHEN@IBM.COM (Norman COHEN)
Newsgroups: comp.lang.ada
Subject: M. Feldman's questions on priorities and preemption in V88 #43
Message-ID: <021688.094857.ncohen@ibm.com>
Date: 16 Feb 88 14:48:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

AI-00032 makes clear that the semantics of the Priority pragma can only
be fulfilled by preempting a lower-priority task when a higher-priority
task becomes eligible for execution.  Since the higher-priority task may
become eligible for execution as a result of the expiration of a delay,
this requires that the run-time system gain control when a delay expires
for a task that has higher priority than some currently executing task.

I can imagine various implementation strategies for achieving this goal,
all of which require timer interrupts:

   o  Before relinquishing control to an application task, the scheduler
      sets a countdown timer for the amount of time remaining until the
      next scheduled delay expiration.  The timer interrupt returns
      control to the scheduler to handle the delay expiration.

   o  An interval timer periodically hands control to the scheduler to
      check whether a delay has expired.  (SYSTEM.TICK yields the length
      of the intervals at which this check is made, not the time between
      ticks of the underlying hardware clock used to generate the
      periodic interrupts.)

   o  Either of the two strategies above may be modified to exploit
      special cases.  For example, the expiration of a delay for a task
      of lowest priority need never generate an interrupt.  It suffices
      for the scheduler to observe, the next time that some other task
      relinquishes control, that the delay has expired.

It is difficult to imagine a strategy that never requires timer
interrupts.

For a compiler that supports only one priority level, the language never
mandates preemption, and there is no need for timer interrupts upon the
expiration of a delay for an inactive task.

A compiler that supports multiple priority levels must support preemption
when two tasks of different priorities are both active and the higher-
priority task contains delays.  When these conditions do not hold,
language-mandated preemption will not arise; a compiler is free to check
for such special cases, either at run time or at compile time, and to
avoid unnecessary timer interrupts.  In particular, in a program for
which all tasks have the same priority (Michael Feldman's case 1), the
run-time system need not receive control when a delay expires; if a
program has ten tasks of priority 1 and one of priority 2, a clever
run-time system can stop generating end-of-delay interrupts when the
priority-2 task terminates.