Re: How-to on using the adacl-gc packages

["Steve Whalen" <SteveWhalen001@hotmail.com>]

Martin Krischik wrote:
> I know at least one memory allocation problem where I have not yet
> found a solution for - no matter how much engineering I have put into
> the problem:
>
> task type T;
> type T_Access is access T;
>
> ...
>
> X : T_Access := new T;
>
> The last I read only recently here was: task types are small - don't
> bother deallocating them. Anybody got any better advice?

Why this is a problem? I think you should control task memory just like
any other. I disagree with those who said it's small so don't bother
deallocating them.

You can create and use Unchecked_Deallocation on X which works fine, as
long as the task is terminated. If the task is not terminated then the
deallocation will fail (silently I believe). If you have a situation
where you're not certain that a task is really "completely" terminated
(completed finalization, etc.), you should check X'Terminated first and
do the deallocation only after X'Terminated returns true.

I don't have code readily available, but one approach I remember that
worked well went something like I describe below. If your application
is doing a lot of tasking, using a more complex approach like this is
worth the effort. An approach like this can also have many benefits
besides memory control (like saving on task creation overhead). The
approach went something like this:

1) Create an array or linked list in which all task access variables
are maintained.

2) Keep additional information about the task access variables in the
list, like a task status, etc....

3) Keep appropriate counters about the tasks like "total number of
tasks", "number of task variables free for reuse" and "number of
terminating tasks", etc.

4) Periodically scan the list if the "number of terminating tasks"
counter is > 0, and confirm task'Terminated for any that were
terminating. Then based on your counters and the needs of the
application, either free the memory from the access variable and task
using unchecked deallocation, or mark it free and/or add it to a "free
list" (keeping a separate free list obviously being a design decision
based on if the task list can get very long, etc.).

5) When starting up a new task, re-use one of the existing task
variables if one is available to save on overhead and minimize growth
of memory.

This can get fairly involved, but approaches like this allow pretty
thorough control over task memory.

Or did I completely misunderstand the problem you were referring to?

Steve