Re: When do Ada compilers make scheduling decisions...

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!usen et.coe.montana.edu!milton!mfeldman@ucbvax.Berkeley.EDU (Michael Feldman)]

In article <1991Oct3.010604.14825@zip.eecs.umich.edu> warack@eecs.umich.edu (Ch
ristopher Warack) writes:
>General question...  When do Ada compilers make scheduling decisions?
>Or, when are context switches possible.  For sake of discussion, consider a
>single processor with multiple tasks.
The LRM never spells this out, but a hint is given in section 9.10 of the LRM
on the ABORT statement, which lists points at which an aborted task can
go abnormal. 
>
>The LRM discusses blocking a task during rendezvous's and completion of
>task activation before beginning the first statement following the
>declarative block or statement following task creation.  What other
>conditions are there?  Are time slice schedulers used?
Time slicing is permitted but not required. Many compilers support
timeslicing, usually giving the user a pragma (e.g. DEC) or a
package (e.g. Meridian) to assert control over the mechanism.
Meridian lets you set the size of the quantum.
>
>When priorities are used, the LRM requires a higher priority task to run
>when both it and a lower priority task are waiting to execute.  What if a
>higher priority task becomes "available" while the lower priority task is
>running (e.g., expiration of a delay statement).
A 1986 Approved Ada Interpretation says, referring to sect. 9.8 on
priorities,
   If an implementation supports more than one priority level, or 
   interrupts, then it must also support a preemptive scheduling
   policy.
My source on this is Karl Nyberg's "Annotated Ada Reference Manual." The
interpretations are interspersed with the text. Detailed citation on request.

>
>What prevents a non-blocking (no-rendezvous, no shared vars, no I/O) task
>from running forever.  (I suppose this may be pathological, since this
>implies that the task does not communicate so cannot do anything useful.)
Depends. If a higher priority task wakes up from a delay, then it must
(by the interpretation above) preempt the lower priority task. If both
tasks are of equal priority, neither has more right to the CPU than the
other, so there's (theoretically) no harm in letting it run forever.
The idea is that tasks of equal priority ought to be written so as to
cooperate. Since time-slicing is not mandatory, this is the only
portable design.

It would not be surprising if you encountered an Ada system that did
NOT preempt a lower-priority task as required above, since the
validation suite did not test this until the current one, 1.11. If
your compiler is an ACVC version behind (your school may not have
the latest!), it will likely not preempt.

>Related, will a task that encounters a "non-termination" bug "hang" the
>whole system?
Quite possibly. Depends on what you mean by "non-termination."
>
>How are shared variables handled?
Read the LRM on "pragma SHARED."
>
>I realize that this may be compiler dependant.  I'm interested in how
>various implementations differ, however.
In that time-slicing is optional, behavior for tasks of equal priority
is indeed compiler-dependent, even if they're up to 1.11 behavior.
Behavior for tasks of different priorities should be increasingly
portable as time goes on, at least that's how it seems to me.
-------------------------------------------------------------------------------
Michael B. Feldman
Visiting Professor 1991-92               Professor
Dept. of Comp. Sci. and Engrg.           Dept. of Elect. Engrg. and Comp. Sci.
University of Washington FR-35           The George Washington University
Seattle, WA 98105                        Washington, DC 20052

mfeldman@cs.washington.edu               mfeldman@seas.gwu.edu
(206) 632-3794 (voice)                   (202) 994-5253 (voice)
(206) 543-2969 (fax)                     (202) 994-5296 (fax)
-------------------------------------------------------------------------------