Re: Ada 95 tasking problems with Ada 83 code

[Richard Riehle <laoXhai@ix.netcom.com>]

Wayne Lydecker wrote:

>
> The original developers of our software were task and generic happy (some
> generics are up to three levels deep).  There is no valid reason that it has
> 100 tasks and I'd like to strip it down to a half dozen or so.

Wayne,

Be careful about this kind of decision.   All too often a designer intuits that less
tasks will be more efficient that more.   In fact,  the ideal for a task-based design
on a single processor, is that every task will always be immediately available to
do its work.   This ideal is frequently unachievable, but one can strive for it.

A corollary of the above statement is that most tasks will spend most of their
life waiting for something to do.   Once that something is actually done,  they
will suspend until asked to do it again.   This means that each task should do the
absolute minimum amount of work.   In particular, keep each rendezvous sparse
to prevent blocking other important actions.

It is not unusual, in fine-tuning a task-based design, to increase the number of tasks,
making each one leaner, instead of reducing the number of tasks.

Of course, it is still essential to do the mathematics on this before making such a
decision.
You must consider context-switching time,  priorities, and a whole host of other related

issues before simply changing the number of tasks in the design.  Also, with Ada 95,
many chores previously handed off to an active task can be more efficiently executed
through a protected type.   If you have not looked at protected types, this would be a
good time to do so.  For a good example of a simple protected variable, see Norman
Cohen's book, Ada As A Second Language,  17.4.4., page 831, from McGraw-Hill,
or, even better, get a copy of Concurrency in Ada, by Alan Burns and Andy Wellings.

Hope this helps,

Richard Riehle