Re: Ada 95 tasking problems with Ada 83 code

[Wayne Lydecker <wayne@mtws.visicom.com>]

Richard Riehle wrote:
> 
> 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

That was exactly what I had in mind.  The majority of our tasks (~75)
are used to synchronize access to the databases.  Most of the rest are
for alarm clocks, which were poorly implemented.  I agree 100% that a
good tasking model works fine for 100+ tasks, but when the tasks have
infinite loops with a "delay duration'small" to allow a context switch
for a type of "round robin" scheduling, it's time for a redesign (which
is really what I want to do).

-- Wayne.