home *** CD-ROM | disk | FTP | other *** search
- From: offer@spock.camb.inmet.com
- Date: 26 Aug 1992 10:16 EDT
- Newsgroups: comp.lang.ada
- Subject: Re: Dynamic Task Creation/Control
- Message-ID: <20600139@spock>
- Path: sparky!uunet!inmet!inmet!spock!offer
- Nf-ID: #R:<1992Aug20:174857:spock:20600139:000:3179
- Nf-From: spock.camb.inmet.com!offer Aug 26 10:16:00 1992
- References: <174857@<1992Aug20>
- Lines: 72
-
-
- > 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
-
-