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
> 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
-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