Re: Interpretation of LRM 13.10.1

[stt@inmet.inmet.com]

With regard to reclaiming storage for a terminated task:

It is useful to distinguish between a "task object" and
a "task".  A "task object" designates a task.  An access type
designates a task object (or a record/array object containing
a task object).  When you perform an unchecked deallocation,
the space for the task object may be reclaimed, and it is erroneous
if some other access value is later used to try to refer
to this task object.  Therefore, it *is* legitimate for
an implementation to free *all* storage associated with a terminated
*task* when the task object is freed (Sorry not to agree with you Jerry!).

However, it is *not* legitimate to free the storage associated
with a task with live sub-tasks (i.e. "completed" but not "terminated"),
nor is it permissible to implicitly abort a non-completed
task when its task object is freed.

Using a relatively simple trick, it is actually possible to
free the space devoted to a task as soon as it terminates,
even if its task object still exists.  The trick is
to store a "generation number" within the task control block,
and bump that number when reusing the TCB for a new task.
The same generation number is stored with the task object,
and a task is considered terminated if the generation number
in its task object doesn't match the generation number in
the TCB it points at.

By the way, the ARG (Ada Rapporteur(sp?) Group) recently decided to reverse
an earlier decision, and consider a reference to a task
outside of its scope as erroneous (the dreaded task-returning function
problem).  This means that TCBs can be reclaimed when the task object's
scope is exited, at the latest.

S. Tucker Taft     stt%inmet@uunet.uu.net; uunet!inmet!stt
Intermetrics, Inc.
Cambridge, MA  02138