TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Harbaugh, John S" <[log in to unmask]>
Reply To:
Harbaugh, John S
Date:
Mon, 9 Aug 1999 13:24:35 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (55 lines)
RM D.2.2 permits implementations to define their own policy identifiers.  A time slicing policy would seem to fulfill the intent of D.2.2(6)

"A task dispatching policy specifies the details of task dispatching that are not covered by the basic task dispatching model. These rules govern when tasks are inserted into and deleted from the ready queues, and whether a task is inserted at the head or the tail of the queue for its active priority. The task dispatching policy is specified by a Task_Dispatching_Policy configuration pragma. If no such pragma appears in any of the program units comprising a partition, the task dispatching policy for that partition is unspecified."

Essentially, this would add another kind of dispatching point in addition to those identified in the annex.

You are correct that dispatching policies are distinct from scheduling.  One could create a scheduler task that would manage time slicing of application tasks, although changes to a task's priority may not take effect immediately.

I'm always curious why someone would choose time-slicing as a dispatching or scheduling mechanism.  It is a poor-man's  attempt to simulate parallelism on a single CPU computer.  Most authors (Ben-Ari, Burns & Wellings, to mention a few) recommend that programs be designed around the idea of concurrency, the _potential_ for simultaneous execution of multiple instructions, rather than parallelism, the required use of multiple processors.  A correct, concurrent Ada program using either preemption or rendezvous can execute on one or many processors.  Contrast this with a parallel program that must rely on time slicing to run correctly on a monoprocessor machine.  Would it not be preferable to use basic language features rather than rely on non-portable implementation policies?

Cheers,

        - John
> ----------
> From:         Roger Racine[SMTP:[log in to unmask]]
> Reply To:     Roger Racine
> Sent:         Monday, August 09, 1999 12:24 PM
> To:   [log in to unmask]
> Subject:      Annex D Compliance
>
> 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."
>
> Roger Racine
> Roger Racine
> Draper Laboratory, MS 31
> 555 Technology Sq.
> Cambridge, MA 02139, USA
> 617-258-2489
>

ATOM RSS1 RSS2