TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Content-Type:
text/plain
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"Harbaugh, John S" <[log in to unmask]>
Date:
Wed, 11 Aug 1999 10:33:42 -0700
MIME-Version:
1.0
X-To:
Roger Racine <[log in to unmask]>
Reply-To:
"Harbaugh, John S" <[log in to unmask]>
Parts/Attachments:
text/plain (38 lines)
        <snip>

> Time slicing is typically used on general-purpose operating systems to
> provide some equality among processes on the use of CPU.  If Ada tasks are
> implemented using processes, they get time slicing.  I have also seen it
> mentioned as used by multilevel secure operating systems to "hide" the
> existance of other processes (low-security-level processes are not allowed
> to even know of the existance of other processes).
>
> For the embedded world, one could think of a multiple-experiment computer
> on some platform.  In that case, multitasking could be used as a poor-man's
> multiprogramming system.  Multiple equal priority tasks might want to run
> "continuously" for a while, sharing the CPU.  Breaking the tasks into small
> pieces is possible, but is a maintenance nightmare.
>
I see your point.  I generally work on firm-to-hard real-time systems that are viewed as a single program containing concurrent activities.  The systems you describe are a collection of programs whose execution is mediated by an OS that knows little of the programs (processes) under its control.  There is certainly a place for this model of execution, but I have also seen cases where developers insist on time slicing or cyclic frame-based executive when a preemptive model could permit higher CPU utilization and improve maintainability.  The Ada 95 revision really opens up new opportunities to write portable multi-tasking programs.

> I certainly agree that there should be a means of turning it off, but that
> is typically a flag within the operating system itself; I am surprised by
> Tucker's reply that validation people would "frown on" something that has
> been in use for so many years.  My assumption here is that the "hard
> real-time" folks insisted on the one named dispatching policy not allowing
> time slicing, and the soft-real-time people were outvoted.
>
We are running into this sort of problem when we are running a preemptive tasking model on a Unix box that uses time slicing.  The Ada code looks slick, but the actual behavior is not per the design.  The hidden time slicing effectively changes the dynamic semantics of the language.  Unfortunately, it is not always possible to turn off the time-slicing.  One wonders how such an implementation can be validated for compliance with annex D.

On a related note, I am curious as to how the Ada run-time system implements dispatching.  Suppose task A is running at the highest software priority and encounters a delay statement.  It then yields the CPU to the next runable task of highest priority.  Okay so far, but what happens when task A's delay expires?  How does the run-time system know it should preempt the running task?  Do implementations rely on a timer interrupt, or poll a list of delayed queues, or something else altogether?  Perhaps one of the implementation folks would care to shed a little light on a murky subject.

> Roger
> Roger Racine
> Draper Laboratory, MS 31
> 555 Technology Sq.
> Cambridge, MA 02139, USA
> 617-258-2489
>
John S. Harbaugh
The Boeing Co.

ATOM RSS1 RSS2