TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Joel Seidman <[log in to unmask]>
Thu, 6 Jan 2000 10:16:05 -0500
Tucker Taft <[log in to unmask]>
Tucker Taft <[log in to unmask]>
text/plain; charset=us-ascii
AverStar (formerly Intermetrics) Burlington, MA USA
text/plain (45 lines)
Joel Seidman wrote:
> Can someone please explain the following  line from the Ada 83 LRM 13.10.1(8):
> "If X designates a task object, the call FREE(X) has no effect on the task designated by the value of this task object....."
> The reason I ask is I am looking at a program that uses new and free (instantiation of U.A.) on task access types, and it seems to have a memory leak. Can this be the reason?

The language certainly does not *require* a storage
leak relating to task access types.

The point of 13.10.1(8) (this is an RM 83 paragraph number,
I presume) is that even if you free the task *object*,
the task itself (i.e. thread of control) will keep running
and generally be unaffected by this action.

When the task finishes, that is when its stack can be reclaimed,
not before.  Whatever space is occupied by the task *object* (typically
just a couple of words) will generally be reclaimed when you
call Free(X).  Note that in Ada 95, there are additional complications
associated with task discriminants, since these are visible to the
running task, but are often stored in the task *object*.  Therefore,
in Ada 95 there is a permission to delay storage reclamation of the
task object when the associated task is still running.

> If the above paragraph means what it seems to mean to me, the stack space of a task allocated with new cannot be reclaimed. If so, this is very surprising to me (but would explain my memory leak), and I'm curious what the reason would be. Or am I misinterpreting the paragraph?

Some Ada 83 implementations had storage leaks associated with tasks because
of a one-time requirement for task objects to persist longer than their
associated master.  This requirement was later dropped, but some
implementations ended up "stuck" with the storage leak.  I recommend
you contact your Ada 83 compiler vendor to see whether they have
a known storage leak associated with tasks.

> Thanks for any enlightenment.
> -- Joel

-Tucker Taft   [log in to unmask]
Technical Director, Distributed IT Solutions  (
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA