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 >