LISTSERV mailing list manager LISTSERV 16.0

Help for TEAM-ADA Archives


TEAM-ADA Archives

TEAM-ADA Archives


TEAM-ADA@LISTSERV.ACM.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEAM-ADA Home

TEAM-ADA Home

TEAM-ADA  March 1998

TEAM-ADA March 1998

Subject:

Re: Exploiting Ada tasking

From:

"Marc A. Criley" <[log in to unmask]>

Reply-To:

Marc A. Criley

Date:

Fri, 27 Mar 1998 18:39:39 -0500

Content-Type:

text/plain

Parts/Attachments:

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2017
November 2017
October 2017
September 2017
June 2017
May 2017
April 2017
January 2017
December 2016
November 2016
October 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
December 2010
November 2010
October 2010
September 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
June 2007
May 2007
March 2007
February 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996

ATOM RSS1 RSS2



LISTSERV.ACM.ORG

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager