Re: Ada 95 tasking problems with Ada 83 code

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

Pat Rogers wrote:

> "Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
> news:39AF2DEC.71D8B897@ix.netcom.com...
>
> <snip>
>
> > Reminder:  you still need to take a look at RMA if you have 100
> concurrent tasks.
>
> I confess I don't see why.  Surely the number of tasks, by itself,
> doesn't require a schedulability analysis.  (There may very well be
> deadlines associated, but that hasn't been indicated as far as I
> know.)  Absent deadlines, then this is "just" a concurrent program, in
> which case the issues are maximizing throughput and ensuring liveness.
> Liveness isn't a function of the number of tasks, so I don't see the
> connection.
>
> On the other hand, let's say there are deadlines.  In that case, a
> static-priority preemptive scheduling scheme may not be the right
> approach (e.g., RMA).  Perhaps a dynamic scheme might be best -- say
> Earliest Deadline First (which is optimal too).  In other words, it
> seems to me that that the info so far -- 100 tasks -- isn't sufficient
> to require use of any schedulability analysis, RMA or otherwise.
>
> (Sure, the more tasks one has the more likely a general-purpose
> tasking system is to bog down, but that is a separate issue I would
> think.)
>
> Of course you know these things, so what am I missing?

Pat,

I am probably just an RMA bigot and believe everyone who is doing anything
with tasking
should have a rudimentary undestanding of it.   Also,  I see RMA as a
larger issue than the
simple static scheduling of its beginnings.   Most treatments of the
subject, including the
Briand and Roy work I cited earlier, do include treatments of both static
and dynamic scheduling.
However, I believe one should understand the static models before moving
on to the
dynamic ones.

As far as liveness and the number of tasks, if there are truly one-hundred
tasks in this design,
it is hard to imagine that they will all be ready to do their work at the
required instant unless
there is some kind of schedulability scheme.   This can be a really simple
scheme or a really
sophisticated one.   The answer to your question is in the last paragraph
of your posting.  When
there a lot of tasks in a design, absent a good scheduling model (dynamic
or static), there is an
increased probability they will "bog down."

The number of tasks may not always be a direct indicator of the need for
schedulability schemes,
but, as you note, as the number of tasks increases, there is a potential
for them to block each other
at inopportune times and bog down the system.    If the tasks are
communicating, this becomes
even more interesting.    If every task is executing at the same
priority,  and there is a lot of
rendezvous occurring,  one can spend many entertaining hours trying to
fine-tune the performance
of the design.

All that being said, we don't know enough details of Wayne's design to
make absolute pronouncements
about how he should proceed, but I think you would agree that anyone
designing a task-based system
ought to have some awareness of the issues related to schedulability.

Richard