Re: Ada 95 tasking problems with Ada 83 code

["Pat Rogers" <progers@NOclasswideSPAM.com>]

"Richard Riehle" <laoXhai@ix.netcom.com> wrote in message
news:39B52DFC.6EF265D3@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.

I'm influenced by the Real-Time Systems Group at York, where both have
received quite a bit of thought.  :-)
All kidding aside, I find some of the dynamic ones, such as EDF, to be
simpler.

> 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."

Humm.  Surely liveness is a property independent of the number of
tasks involved.  A "correct" concurrent program should work no matter
how many tasks exist.  The "finite progress assumption" tells use that
all tasks in a correct concurrent program will eventually run.

I think what you're saying is that a large number of interacting tasks
more likely justifies an analysis of the interactions -- a very
reasonable assertion -- such that some idea of the effective
throughput can be determined.  This determination can then be used to
critique the design.  If so, that seems very reasonable.

Perhaps I have a design in the back of my mind that is biasing my
perception of the effect of the number of tasks.  If most of the tasks
are different (i.e. of a different type) then yes, the idea that they
will all be ready to run at a critical instant seems unlikely, and
some idea of the throughput seems worthy of analysis.  On the other
hand, I often like to have pools of tasks, all of the same type, ready
to do the work that becomes available.  In such a case it might not be
unusual for there to be quite a few created, although most might not
be running at any given moment.  As you say, increasing the pool size
can then be a way of increasing throughput.


> 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.

In truth I was really just thinking of the fact that most
general-purpose tasking system implemenations use dynamic data
structures whose performance degrade as they grow in length.


>
> 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.

Certainly for a real-time system.  But for "just" a concurrent
program, I think a full schedulability analysis is overkill.

Pat