TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To: "Marc A. Criley" <[log in to unmask]>
Date: Sat, 28 Mar 1998 12:58:06 -0800
Reply-To: AdaWorks <[log in to unmask]>
From: AdaWorks <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
Parts/Attachments: TEXT/PLAIN (24 lines)
On Fri, 27 Mar 1998, Marc A. Criley wrote:

> First I want to thank everyone who responded to my request for
> information regarding the use of a significant number of Ada tasks
> within processes.  I got some good pointers, and between them and some
> pointed arguing I believe I've successfully shown that the number of
> tasks in our software in no way endangers quality or success, and
> never did.

  The notion that too many tasks spoils the program is a persistent
  myth. In a task based design the ideal is that every task is always
  ready to do its work.  One could easily conceive of design where every
  task is idle most of the time so it can handle each event when it
  occurs.  For some reason this is counter-intuitive for some designers.

  And yes, I do realize that this is something of an oversimplification
  and does not, by itself, solve all of schedulability problems in a real
  system.

  The design described by Marc is probably important for its contribution
  to understanding how myth and reality are so different in Ada tasking.

  Richard Riehle

ATOM RSS1 RSS2