Tasking and delays, again

[MFELDMAN@GWUVM.BITNET (Mike Feldman)]

OK. Here is one last question on task scheduling (at least I think it's
the last one). I hope some tasking authorities can put this issue to
rest - I'm trying to get the last number of postings on the subject
straight in my mind.

SCENARIO: We have a single processor. Task A is delayed (say 60 seconds).
Task B is running. These are the only two tasks. Task B does nothing in
particular to "put itself to sleep" or block itself, thus is executing
only sequential statements with _no_ entry calls, delays, or whatever.
My question has to do with whether, under recent interpretations, a
run-time system _must_ discover the expiration of Task A's delay.

Suppose, for example, that Task A's 60 seconds are up. Is it _required_
that there be some sort of interrupt so that Task B stops long enough
for "someone" to figure out that Task A is now "eligible to run"?
If not, what would ever make Task B give up control? Now let's consider
three sub-cases:

1. A and B have the same priority

2. A has higher priority than B

3. B has higher priority than A

If I read the recent discussion of AI-something correctly, a legal
system in which 2 or 3 is even possible must, somehow, interrupt. Am
I correct in this reading? Does it make any difference if case 1
obtains?

I think this question goes to something fundamental in our collective
understanding of how tasking is supposed to work. I am aware of several
(validated, of course) compilers in which (I think that) the expiration
of A's delay would be noticed only when (if) B did something to block
itself. Does anyone else know of such compilers? If they support multiple
priorities, are they now illegal?

If anyone out there is aware of the appropriate AdaBoard interpretation,
please E-mail it to me if you can get it. I'm not sure how to do it, or
which interpretations apply. Thank you very much!

Michael B. Feldman, Professor
Dept. of EE&CS
The George Washington University
Washington, DC 20052
MFELDMAN@GWUVM.BITNET