Nf-ID: #R:<1992Aug20:174857:spock:20600139:000:3179
Nf-From: spock.camb.inmet.com!offer    Aug 26 10:16:00 1992


>     The area where wisdom is needed deals with the dynamic creation of tasks. 
> Since Ada tasking essential keeps the memory assigned to an access type
> task until termination of the task that has the access type defined, I am 
> forced to create a 'task-control-block' that keeps track of which tasks 
> are currently being used.  In addition, I have to try and reuse these 
> tasks for different 'procedural code'.  Any suggestions?
>     Also, when 'it is decided' to terminate a task ( done normally because it
> has passed it's deadline ), I need to reclaim the task-control-block and 
> be able to reuse it.  

As for Ada 83, you are pretty much at the mercy of the sepcific vendor your 
working with since most of the behavior you're requesting is implementation
defined.

Unchecked_Deallocation on the tasks (afetr they terminate) might solve some
of the problem, although it is not uniformly implemented for tasks.

Second, it seems from your note that the "limitation of the access task types"
is artificial in your case.  If this is true, than you don't have to have the
access to task types, so "high" in the scope.  If your tasks serve mainly as
containers or as the execution threads for dynmaically chosen procedures, 
then it seems that the task types (entries profile, bodies, etc) themselves 
don't vary much.  Therefore, the same access to task type X1 does not have
to be shared by the entire program, and instead it can be declared in a deeper
scope.  Doing so will more likely cause the implementation to release task
space when the (deeper) scope is exited.  You may also still use the same
task type, but with multiple access-to-task-types declared in various places,
but in order to be more specific, one has to know more about the inter-
dependencies of the tasks, their interaction, data visibility, etc.

You've talked about a TCB; I assume that this is YOUR TCB, not the RTS
one.  I also assume that it is there just to keep track of re-usable tasks
and if the problem of reclaiming the storage was gone, you did not need this
construct.  If this is so, then the problem of deallocating the TCB's is gone
too.


In the proposed Ada 9X, you life may be a bit easier; there are several 
features that can help here.

1. User-defined allocators, will allow you to intervene in allocation/
   deallocation and to do the right thing.

2. You'll be able to allocate storage pools for certain purpose with 
   specific life time.

3. With ROOT_TASK_CLASS and the TASK_IDENTIFICATION package, you'll be able 
   to more eaasily manipulate task objects on your own.

4. Finalization will also help you get rid of objects in a more controlled
   way.

Most of these features are not in the planned core, but rather in the
System Programming and Real-Time annexes.

The above list is not intended to be complete or self-explanatory.  Check
the appropriate 9X documents, if you are interested.

> However, I am at a loss to come up with a good way to 
> insure it is in a known state.  Again, any suggestions?
                    ^^^^^^^^^^^

I am not sure I understand this problem, assuming that my interpretation
of the TCB is correct.



Offer Pazy

MRT