TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 6 Jan 2000 09:57:43 -0800
Reply-To: Joel Seidman <[log in to unmask]>
From: Joel Seidman <[log in to unmask]>
Content-Transfer-Encoding: quoted-printable
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Parts/Attachments: text/plain (56 lines)

Thanks for the on-target reply (as usual). 

(I should have mentioned explicitly I'm using VADS (Ada83), which is why I cited the Ada83 RM.)

To be explicit, in the program I am looking at, the task is terminated before the FREE. I was assuming the FREE (U.D.) was to assure that the memory used for the task stack, which could be several hundred K in this case, would become available for reuse. For my improved understanding, could you clarify your statement that a task object is typically a couple words. I have always thought that the "task object" was the entire stack used by the task, probably because of the association of the storage_size attribute with the task. Are you are saying that is not the case? 

-- Joel

>>> Tucker Taft <[log in to unmask]> - 1/6/0 7:16 AM >>>
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