Deallocation of T'STORAGE_SIZE for a terminated task

[prindle@NADC.ARPA (Frank Prindle)]

Given:

 1. An allocator may be used with a task type to dynamically activate a task as
 a consequence of 9.3(6).  The run-time system reserves <task_type>'STORAGE_SIZE
 storage units for use by this activation as stated in 13.7.2(14).

 2. The task thus activated may eventually become completed and terminate as a
 consequence of 9.4(5,6).

 3. The task object allocated is considered inaccessible once the task has
 terminated as a consequence of 4.8(7).

 4. An implementation may (but need not) reclaim the storage reserved for the
 task object once it has terminated, as stated in 4.8(7).

 5. Automatic deallocation, when available, may be selectively inhibited via
 pragma CONTROLLED as a consequence of 4.8(10).

 6. Explicit deallocation of storage reserved for a dynamically allocated object
 is provided by instantiation of UNCHECKED_DEALLOCATION, as stated in 4.8(12).

 7. An instantiation of UNCHECKED_DEALLOCATION for a task object is guaranteed
 to have ***NO*** effect on the task designated by the task object by
 13.10.1(8)!

Then:

 If an implementation does not provide for automatic storage deallocation, what
 mechanism allows the repeated execution of dynamically activated tasks without
 eventual consumption of the entire heap (or that partition reserved for
 task objects) and the subsequent irrecoverable STORAGE_ERROR?

Notice that everything made sense up through point 6 above.  The
implication was that one could not rely on an implementation to reclaim
dynamically allocated storage at the appropriate time, and should always
explicitly deallocate every object explicitly allocated (once it has been
determined that the object is no longer required).  It is further implied
that a simple test of the 'TERMINATED attribute of the task object would
suffice to determine when a task object (i.e. the stack for use by a task
activation) is no longer required.  The killer is 7 above.  When 13.10.1(8)
says "no effect on the task", does this imply that the storage is not to be
deallocated?  But that is the very job intended to be performed by this
generic library procedure, as stated in 4.8(12)!

I think we need a clarification of 13.10.1(8) here, because at least one
implementation has taken it to mean that the storage cannot be deallocated.
Therefore, dynamic activation of transient tasks (i.e. tasks which will
eventually terminate on their own) appears to be a lost cause.

It is quite possible that yet another section of the LRM clarifies this
question, but the index leads me only in an endless circle of the paragraphs
cited above.  Any pointers would be warmly welcomed.

Sincerely,
Frank Prindle
Prindle@NADC.arpa