Roger Racine wrote:
>
> I am having a debate with someone about the possibility of allowing time
> slicing within Ada programs if the Annex D standard task dispatching policy
> is followed.
>
> His position (if I have it correctly) is that time slicing is specifically
> forbidden.  He takes his position from the RM, section D.2.2.  My position
> is that time slicing is allowed.  My position comes from reading the
> Rationale, section D.2.1, the last paragraph of the section:
>
> "Another anticipated application requirement is for time slicing.
> Implementation-defined time-slicing schemes may conform to this
> specification by modifying the active or base priority of a task, in a
> fashion similar to that outlined for EDF scheduling."
>
> Obviously, if the RM specifically forbad time-slicing and the Rationale
> allowed it, the RM would take precedence.  But it is not quite that
> straightforward.  The Rationale distinguishes between task dispatching and
> task scheduling.  The RM does not seem to make this distinction.  And the
> Rationale language is in a context of scheduling policy, not dispatching
> policy.
>
> I hope this is something that can be answered with "Oh, the Rationale
> language is meant for some other dispatching mechanism", or "The Rationale
> is wrong; no complying runtime system can change priorities at will", or
> "The Rationale is correct. Compiler XYZ has been validated for Annex D and
> allows time slicing."


Time slicing is forbidden in the presence of the pragma
Task_Dispatching_Policy(FIFO_Within_Priorities).  In the absence
of this pragma, even on a compiler that "supports"
annex D, the run-time may (but need not) allow time-slicing.
So I suppose you are both right.

There are ways to weasel out of suppressing time-slicing by claiming that the
time slicing happens "automatically" in the lowest level bowels
of the underlying operating system, but the validation gang generally
frown on this.  For a real-time system, it is expected that the Ada
run-time must be able to prevent time slicing if the FIFO_Within_Priorities
dispatching policy is requested, or appropriately reject the pragma.

> Roger Racine
> Draper Laboratory, MS 31
> 555 Technology Sq.
> Cambridge, MA 02139, USA
> 617-258-2489

--
-Tucker Taft   [log in to unmask]   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA