Marc,
Would you characterize this system as hard-real-time? The architecture
you describe sounds highly "pipelined". Is that a correct assumption?
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
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
************************************************************************
******************
> ----------
> From:         Marc A. Criley[SMTP:[log in to unmask]]
> Reply To:     Marc A. Criley
> Sent:         Thursday, March 26, 1998 8:49 AM
> To:   [log in to unmask]
> Subject:      Exploiting Ada tasking
>
> 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
>