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]>
Date: Fri, 27 Mar 1998 18:39:39 -0500
MIME-version: 1.0
Reply-To: "Marc A. Criley" <[log in to unmask]>
Content-type: text/plain; charset=us-ascii
From: "Marc A. Criley" <[log in to unmask]>
Organization: Lockheed Martin M&DS
Content-transfer-encoding: 7bit
Parts/Attachments: text/plain (257 lines)
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.

Some other side questions were asked in response to my post, so I'm
grouping them altogether into one response rather than sending out
several single responses.

Thanks for the interest.

Marc


>Date: Thu, 26 Mar 1998 10:39:38 -0500
>From: Mike Brenner <[log in to unmask]>
>Subject: RE> Exploiting Ada tasking
>Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
>To: [log in to unmask]
>Reply-to: Mike Brenner <[log in to unmask]>
>
>  > Each of the key entities in this subsystem has two tasks
>  > associated with it, one to manage access/update and the
>  > other to move it down its timeline. Since there can be 128
>  > of these entities that means 256 tasks, and with a
>  > bunch of "utility tasks" results in a process have 300-350 tasks.
>  >
>  > Our experience with tasking in this subsystem has been very positive, most
>  > of the tasks are dormant at any given time, resulting in
>  > very low CPU utilization.
>  > In addition, since each pair of tasks has no interaction
>  > with other pairs, the complexity is quite low.  And, in fact, the
>  > abstraction of the problem domain closely matches tasking
>  > semantics and capabilities.
>
>First, please submit a paper at this year's Tri-Ada giving the
>tasking organization of your product and timing metrics and
>a timing chart. This is great stuff.

Sooner or later there will be a paper or two.  I've always been
skeptical of "this is what we're doing and it's _going_to_ work really
great!" vs "this is what we did and here's how it worked".  We'll be at
the latter point in a few months and I'll probably crank one out at
that time.  All indications have been, and continue to be, _very_
positive.


>
>Second, if you could produce a public version of your code
>(by deleting almost everything except the tasking shells),
>it would be great to use it as an exercise to convert it
>to Ada-95 protected records. An actually used tasking structure,
>especially one like this matches Dr. James' cascading matrix
>of Secretary-Protected-Records which administer the active
>Protected-Records on either side of them. I have been waiting
>for exactly such an example as yours to program as a
>cascading matrix of protected records.

Okay, to put it plainly, I don't know what you're talking about :-)
And it sounds like something far more sophisticated that what I'm
doing.  Basically all I've got is two task types, a manager and a
scheduler, with a pointer to each residing in the object's data
record.  Then I've got an array of these records.  Pfft, that's it.

The manager oversees updates and state changes to the object, while
the scheduler waits for significant time events that will occur during
the object's lifetime, initiating the appropriate actions at each
interval.  It's actually quite slick!  :-)


>
>Third, although you are in Ada-83, most Ada-95 compilers have
>Ada-83 parser options, so this could be simulated in DOS.
>Also, most Ada-83 compilation units compile unchanged in Ada-95.
>It would also be interesting to know if a conversion from your
>tasking structure to protected records could be done
>incrementally. Perhaps one pair of tasks at a time converting
>to a pair of protected records? It would depend on how many
>inter-task connections there are. Is it 1-dimensional?
>2-dimensional?

A pilot effort to move to Ada 95 is underway, we're waiting for some
programmatic issues to resolve themselves before we can complete it.
And yes, the intent is to convert a number of the auxiliary task types
into protected records.


>Date: Thu, 26 Mar 1998 11:19:55 -0600
>From: [log in to unmask] (Stanley Allen)
>Subject: Re: Exploiting Ada tasking
>To: "Marc A. Criley" <[log in to unmask]>
>Cc: [log in to unmask]
>
>Marc A. Criley wrote:
>
>> What I'm looking for is experience (anecdotal is fine) wherein at least 250
>> tasks are simultaneously active within a single process.  I'm focusing more
>> on the _tasking_ aspects than on the potential complexity of the system in
>> which they're used--as I noted, this part of the system is not terribly
>> complex, it just uses a lot of tasks.
>>
>
>You're in luck.  A paper on *this very topic* was
>presented at Tri-Ada '96, *and* the paper is
>available online for your perusal, *and* the
>paper favorably reports on this design approach.
>
>>> http://sw-eng.falls-church.va.us/AdaIC/docs/reports/gramp/kg/kgpaper.htm
>
>Stanley Allen

That paper is now on my desk and the reference was passed on.

Thanks!


>Date: Fri, 27 Mar 1998 11:04:18 -0500
>From: "Fowler, Kenneth" <[log in to unmask]>
>Subject: RE: Exploiting Ada tasking
>To: [log in to unmask], "'Marc A. Criley'" <[log in to unmask]>
>Cc: "[log in to unmask]" <[log in to unmask]>
>
>Marc,
>Would you characterize this system as hard-real-time? The architecture
>you describe sounds highly "pipelined". Is that a correct assumption?

The system is soft real-time.  Most state changes occur as a result of
operator interaction, though asynchronous updates are received from
various sources.  These need to be quickly assimilated and may drive
operational changes as well as updates to operator displays.  But no,
there are no hard deadlines that must be met, well, there are in terms
of seconds, but not micro or milliseconds.

I'm not sure I'd call it pipelined, it's more a big pool of
encapsulated data that is responding to various stimuli, and
generating some of its own based on its execution timeline.


>Also, are all tasks statically declared or are they created/destroyed
>"on-the-fly"? Do you have any concerns about schedulability (RMA?)
>and/or memory-management (run time garbage collection). I'm making the
>assumption that this is an embedded application. Was the tasking design

Most tasks are dynamically allocated, especially for those objects of
which the number may vary.  Again, as it's operator interaction that
triggers the creation of the task, the time to do so has not been a
concern.

Most of the time nearly all tasks are suspended on a delay alternative
and operate quite independently of one another, hence schedulability
is not much of an issue.  A task will awaken, execute some amount of
functionality, then suspend itself while waiting for the next event of
interest to occur, which can be minutes or hours away.  Even maxed out
on tasks, the CPU utilization is surprisingly low (to the uninitiated
:-)

Regarding GC, we've found that completed tasks are "reused" by new
allocations, so there is a finite limit to the amount of memory that
will be used by the tasking.  (There's a maximum number of objects,
therefore a maximum number of tasks).

>based on a standard paradigm, e.g., Burns and Wellings? This
>correspondence probably belongs on info-ada news group rather than
>team-ada but I couldn't resist. :-)
>Cheers,
>--Ken Fowler
>                       (standard disclaimer)
>******************************************************************************************
>Kenneth J. Fowler
>Tel  973-398-0944
>Lead Software/Systems Engineer, W077                           Fax 973-398-2562
>Software Technology and Information Services                  Email [log in to unmask]
>The MITRE Corporation     __        __  __                     111 Howard Boulevard
>Suite 214                        |__| _| _ |__||__                  Mount Arlington
>New Jersey                     |   | |_||_|_  | __|                 07856
>******************************************************************************************



>Date: Fri, 27 Mar 1998 08:16:48 -0800
>From: "Robert C. Leif, Ph.D." <[log in to unmask]>
>Subject: Re: Exploiting Ada tasking
>To: "Marc A. Criley" <[log in to unmask]>
>
>To: Marc A. Criley
>From: Bob Leif, Ph.D.
>
>Since I am both a taxpayer and an Ada fanatic, I must ask why are you
>staying with Ada 83, when the Ada 95 protected types should simplify your
>problem and significantly increase your efficiency. This becomes even more
>critical, since GNAT is freely available on the web to possible future
>recipients of your Tomahawks.

We're still using Ada 83 solely due to programmatic considerations,
the required OS upgrade has not yet been okayed by the contracting
office.  At that time a plethora of Ada 95 compilers will be available
on our platform.

A pilot project to port the software to Ada 95 and a new compiler is
underway.  The latter of which is driving the most changes, at least
initially (replacing compiler-specific coding with Ada 95 features).
When I began the redesign and rewrite of this software over a year
ago, it was with the intention of transitioning to Ada 95 at some
point in the future, so certain techniques were used that will exploit
Ada 95 features.  For instance, much of the module design is oriented
towards a "hierarchical package" paradigm, so this will play quite
well after the transition.

We are certainly looking forward to exploiting Ada 95 in the near
future, in the meantime we grind our teeth :-)


>
>
>At 08:49 AM 3/26/98 -0500, you wrote:
>>Greetings,
>>
>>A key subsystem of the project on which I work, the Advanced Tomahawk
>>Weapon
>>Control System (ATWCS), was recently rewritten.  In its new incarnation it
>>heavily exploits Ada tasking.  This, by the way, is still written in Ada
>>83.
>>
>>Each of the key entities in this subsystem has two tasks associated with
>>it,
>>one to manage access/update and the other to move it down its timeline.
>>Since there can be 128 of these entities that means 256 tasks, and with a
>>bunch of "utility tasks" results in a process have 300-350 tasks.
>>
>>Our experience with tasking in this subsystem has been very positive, most
>>of the tasks are dormant at any given time, resulting in very low CPU
>>utilization.  In addition, since each pair of tasks has no interaction
>>with other pairs, the complexity is quite low.  And, in fact, the
>>abstraction
>>of the problem domain closely matches tasking semantics and capabilities.
>>
>>Recently at an internal design review, a concern was raised about the
>>"excessive tasking" being "moreso than is commonly found".
>>
>>What I'm looking for is experience (anecdotal is fine) wherein at least 250
>>tasks are simultaneously active within a single process.  I'm focusing more
>>on the _tasking_ aspects than on the potential complexity of the system in
>>which they're used--as I noted, this part of the system is not terribly
>>complex, it just uses a lot of tasks.
>>
>>Thanks for any assistance.
>>
>>--
>>Marc A. Criley
>>Chief Software Architect
>>Lockheed Martin ATWCS
>>[log in to unmask]
>>Phone: (610) 354-7861
>>Fax  : (610) 354-7308

ATOM RSS1 RSS2