MFELDMAN@GWUVM.BITNET (Mike Feldman) (02/16/88)
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
FACFELD@GWUVAX.BITNET (02/16/88)
OK, Ada sports fans! I tried answering my own just-submitted
question with the following program. Note that A has higher
priority than B; A sleeps on (roughly) 5-second cycles and
B never explicitly sleeps at all.
I tried this on four different compilers. On
Meridian AdaVantage 2.0 (IBM PC/AT),
TeleSoft TeleGen2 3.13 (VAX/VMS), and
Verdix VADS 5.41 (VAX/VMS)
Task A wrote its first message and, by several _minutes_ later,
had not written a message again. Task B got control and kept it.
On Verdix VADS 5.41 (Sun 3 Unix), A actually wrote a message
now and then, but at longer than 5-sec intervals (to be fair,
there was a lot of 1200-baud terminal I/O going on, right?).
By the way: Ada/Ed-C (IBM PC/AT) wouldn't compile the program -
some sort of "internal error" diagnostic.
So - Susan Flynn, Robert Eachus, Robert Firth, John
Goodenough, whoever: are 3 of these compilers now illegal?
If not, what ever does "preemptive scheduling" mean?
--------------------------------cut here-----------------------
with TEXT_IO, CALENDAR ; use TEXT_IO, CALENDAR;
procedure WAKEUP is
package DURATION_IO is new FIXED_IO(DURATION);
use DURATION_IO;
package INT_IO is new INTEGER_IO(INTEGER);
use INT_IO;
task A is
pragma PRIORITY(5);
entry START;
end A;
task B is
pragma PRIORITY(2);
entry START;
end B;
task body A is
begin
accept START;
loop
PUT("********TASK A HERE"); PUT(SECONDS(CLOCK)); NEW_LINE;
delay 5.0;
end loop;
end A;
task body B is
begin
accept START;
loop
PUT("TASK B HERE"); PUT(SECONDS(CLOCK)); NEW_LINE;
--delay 5.0;
end loop;
end B;
begin -- MAIN
A.START;
B.START;
end WAKEUP;John.Goodenough@SEI.CMU.EDU (02/16/88)
Given that subtype PRIORITY includes the range 2..5 (so the pragmas have an effect), task B should be interrupted approximately every 5 seconds and task A should then execute until the next delay statement. Even in a multiprocessor implementation, one would expect task A to output its text every 5 seconds or so. An implementation might delay interrupting task B until the end of one of the I/O statements if I/O is implemented by a task that runs at higher priority than task A. In my opinion, your test shows that the implementations do not support preemptive scheduling (assuming the priority range includes 2..5), and therefore, do not conform to the Standard (and AI-00032). With respect to your initial question, if tasks A and B have the same priority, task B can run forever once it gets control, assuming a uniprocessor implementation. On the other hand, if the uniprocessor implementation supports time-slicing, then task A could occasionally get control. The current validation tests do not, to my knowledge, test pragma PRIORITY, in part because I hadn't interpreted 9.8 as requiring preemption. Your test gives an example of how this could be tested, however.
wes@wsccs.UUCP (Barnacle Wes) (02/27/88)
In article <8802160441.AA16876@ajpo.sei.cmu.edu>, MFELDMAN@GWUVM.BITNET (Mike Feldman) writes: > 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 can't answer your questions, unfortunately, but I do know of some code for an Air Force command and control system that would break (horribly) if the Ada compiler did not support pre-emption. By pre-emption I mean: process A has a higher priority than process B process B is currently running process A becomes ready to run due to some event most of the executives I have worked on in command and control systems need to be guaranteed that A will run within a specified amount of time, or they would not work at all. C2 messages would be scrambled or lost. Does the Ada language allow tasking systems that do not support time-slicing of some sort on single-processor systems? -- /\ - " Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes