Deallocating Task objects

Deallocating Task objects

[Jonas Nygren]

I sent out a question to c.l.a about how to reclaim memory for tasks
that are dynamically allocated. Since then I have been trying to find 
some 'nice' way of doing this.

I have identified one sentence in the Ada RM that seems to provide
some sort of automatic storage reclamation. The sentence is found in 
13.11(18) and reads:

"If Storage_Size is specified for an access type, then the Storage_Size 
 of this pool is at least that requested, and the storage for the pool 
 is reclaimed when the master containing the declaration of the access 
 type is left."

This seems to provide some sort of 'garbage collection'. One have
to give an upper bound on the number of allocatable objects but this is
quite acceptable for my code.

I wonder if somebody can confirm that my interpretation of this sentence
is correct. Below I have attached a small tasking example with one
Main_Task that dynamically allocates Sub_Tasks and I want to be absolutely 
sure that the storage used for the Sub_Tasks have been reclaimed when the
Main_Task instance, A_Main_Task, goes out of scope.

Have I interpreted the 13.11(18) sentence correctly? Is the construct 
portable between different Ada compilers?

/jonas

PS of course I could have defined an array of Sub_Tasks instead but then
   there would have been the added complexity of synchronizing the
Main_Task's
   stack size with the number of allocated Sub_Tasks. DS

PPS I have tried this with Gnat 3.09 for NT and Win95 and it will only
handle
    a maximum of 57 Sub_Tasks. With 58, or more, Sub_Tasks it will just
hang 
    in the allocator, without any errors. I will report this bug to ACT.
DDS

-- code follows

with Text_IO;
procedure Test is
   task type Main_Task (Max_Sub_Tasks : Positive);

   task body Main_Task is

      task type Sub_Task is
         entry Dummy;
      end Sub_Task;

      type Sub_Task_Ref is access Sub_Task;
      for Sub_Task_Ref'Storage_Size use Max_Sub_Tasks * Sub_Task'Size; --
13.11(18)

      task body Sub_Task is
      begin
         loop
            select
               accept Dummy;
            or
               terminate;
            end select;
         end loop;
      end Sub_Task;

      A_Sub_Task : Sub_Task_Ref;
   begin
      for I in 1..Max_Sub_Tasks loop
         A_Sub_Task := new Sub_Task;
	  Text_IO.Put_Line(Integer'Image(I));
      end loop;

      delay 1.0;
   end Main_Task;
begin
   declare
      A_Main_Task : Main_Task(1000);
   begin
      null;
   end;
   -- at this point all storage allocated for Sub_Task objects
   -- in A_Main_Task will have been reclaimed
end Test;

Re: Deallocating Task objects

[Robert Dewar]

Jonas asks

<<I wonder if somebody can confirm that my interpretation of this sentence
is correct. Below I have attached a small tasking example with one
Main_Task that dynamically allocates Sub_Tasks and I want to be absolutely
sure that the storage used for the Sub_Tasks have been reclaimed when the
Main_Task instance, A_Main_Task, goes out of scope.
>>

I would not call this garbage collectoin in any sense. it is more like
the PL/1 area concept. Note that you can trivially do something like
this yourself by using the storage pools mechanism. Indeed the way this
is accomplished at least in GNAt is precisely by using the storage pools
mechanism.

Re: Deallocating Task objects

[Mats Weber]

Jonas Nygren wrote:
> I wonder if somebody can confirm that my interpretation of this sentence
> is correct. Below I have attached a small tasking example with one
> Main_Task that dynamically allocates Sub_Tasks and I want to be absolutely
> sure that the storage used for the Sub_Tasks have been reclaimed when the
> Main_Task instance, A_Main_Task, goes out of scope.
> 
> Have I interpreted the 13.11(18) sentence correctly? Is the construct
> portable between different Ada compilers?

No, the guarantee that the space occupied by the tasks is reclaimed is
not portable. On most systems, the size (as given by 'Size) of a task
object is 32 bits (the size of a pointer), and the task object is just a
pointer to memory that describes the task. What 13.11(18) guarantees is
that the space occupied by these pointers is reclamed, but not the space
occupied by the tasks themselves (i.e. their stack, etc.).

The approach the we are using for such cases is to have a free list for
each task type that is allocated dynamically. When such a task finishes
its work, it appends itself to this free list, and it can be reused
later when a new task is needed. We then terminate the tasks in the free
lists on program termination.

It was absulutely necessary to use this approach five years ago with DEC
Ada and Verdix Ada because these implementations always kept some memory
allocated for tasks pointed to by library-level access types. I don't
know if it's still required, but we continue using that approach because
it's not much extra work as we have a generic package that we
instantiate for this purpose, and it automatically gives us some
information on how many tasks of each type we dynamically allocate.

Re: Deallocating Task objects

[Robert L. Spooner]

Mats Weber wrote:
> 
> It was absulutely necessary to use this approach five years ago with DEC
> Ada and Verdix Ada because these implementations always kept some memory
> allocated for tasks pointed to by library-level access types. I don't
> know if it's still required, but we continue using that approach because
> it's not much extra work as we have a generic package that we
> instantiate for this purpose, and it automatically gives us some
> information on how many tasks of each type we dynamically allocate.

For Ada 83 some memory had to be kept so that the task attributes such
as 
T'terminated could be used.  I don't know enough about Ada (95) yet to
know 
if it is still necessary.
-- 
                               Robert L. Spooner
                        Registered Professional Engineer
                               Research Assistant
                        Guidance and Control Department

               Applied Research Laboratory        Phone: (814) 863-4120
               The Pennsylvania State University  FAX:   (814) 863-7843
               P. O. Box 30
               State College, PA 16804-0030       RLS19@psu.edu

Re: Deallocating Task objects

[Robert A Duff]

In article <3309C668.7D8E@Sor.psu.edu>,
Robert L. Spooner <rls19@psu.edu> wrote:
>For Ada 83 some memory had to be kept so that the task attributes such
>as T'terminated could be used.  I don't know enough about Ada (95) yet
>to know if it is still necessary.

The case is where a function returns a task object that is local to the
function.  I believe there was an Ada 83 AI that "clarified" that this
case was erroneous, so that storage for the task could be deallocated
upon leaving the function.  (In the standards business, "clarified" is a
euphemism for "fixing a bug in the language".  ;-))  Unfortunately, this
fix was made after ACVC tests had already forced implementers to keep
that storage around.

In Ada 95, this case raises Program_Error.  The error can actually be
caught at compile time, except in some cases involving generics -- a
good compiler will warn at compile time.

See AARM-6.5(20.a-20.d, 24.a-24.b) for some discussion of this stuff.

- Bob

Re: Deallocating Task objects

[Robert Dewar]

Bob Duff said

<<The case is where a function returns a task object that is local to the
function.  I believe there was an Ada 83 AI that "clarified" that this
case was erroneous, so that storage for the task could be deallocated
upon leaving the function.  (In the standards business, "clarified" is a
euphemism for "fixing a bug in the language".  ;-))  Unfortunately, this
fix was made after ACVC tests had already forced implementers to keep
that storage around.

In Ada 95, this case raises Program_Error.  The error can actually be
caught at compile time, except in some cases involving generics -- a
good compiler will warn at compile time.>>



The history is not quite right, and is interesting. The Ada 83 RM does
indeed imply (but a not entirely obvious chain of reasoning), that a
function can return a local task, and the caller can check if it is
terminated. 

Jean Pierre Rosen noticed this and considered it an obvious bug in the
design. Confident that the ARG would fix this, he submitted it as an
issue. Amazingly, the ARG voted that this behavior was intended and
must be required. The consequence is awful, the only reasonable
implementation is to keep tasks around much longer than is needed.

At the following meeting of WG9, Jean Ichbiah and I launched an energetic
attempt to convince WG9 that this was NOT one of the ARG decisions that
should be approved. We lost, largely because Ron Brender of Digital
announced that this could be implemented without any negative impact.
(An ironic claim, since in fact the way that Digital reacted to this
ruling, like other vendors, was to delay freeing of locally allocated
tasks in this situation.

The ACVC suite, in the business of enforcing ARG decisions, then produced
tests that required this to work (how any one could possibly think this
was useful is beyond me). Implentors dutifully implemented it (at least
in the case of Digital and Alsys, this was done simply by not freeing
tasks completely in this situation, causing an annoying storage leak).

Much later, the ARG visited this issue, and declared that this situation
was pathological, which meant that no compiler was expected to implement
it (I do not remember if it was formally declared erroneous or not, I
don't have my AI's with me right now). This meant that the test was
challengable, but in fact, to my memory it did not get challenged, since
this was late in the Ada 83 cycle.

Finally, it was fixed, in a rather nice and general way in Ada 95.

Anyone want to add to or amend this bit of history (trying to remember
things from this far back in detail is always a bit unreliable :-)

Re: Deallocating Task objects

[Norman H. Cohen]

Robert Dewar wrote:

> Much later, the ARG visited this issue, and declared that this situation
> was pathological, which meant that no compiler was expected to implement
> it (I do not remember if it was formally declared erroneous or not, I
> don't have my AI's with me right now). This meant that the test was
> challengable, but in fact, to my memory it did not get challenged, since
> this was late in the Ada 83 cycle.

It was not declared erroneous in Ada 83.  The ARG defined a new AI
category, "pathological", which said that the question at hand had
nothing to do with anything that could ever be useful in a real program,
and that even if the language gave a definite answer to the question, it
was not useful to write an ACVC test that would force implementors to
degrade their code to conform to that answer.  The later AI simply
reclassified the earlier AI from "binding interpretation" to
"pathological", meaning "Yes, a terminated task can be returned outside
of its master, but it's utterly useless to write a program that does
this, so we don't care if it works right, and we don't want implementors
degrading their implementations to make it work right."

However, as Robert notes, the implementors had already gone through all
the work of degrading their implementations, so the damage was done.

> Finally, it was fixed, in a rather nice and general way in Ada 95.

Yes, it falls out naturally as a consequence of more general rules about
"return by reference".

> Anyone want to add to or amend this bit of history (trying to remember
> things from this far back in detail is always a bit unreliable :-)

This time Robert's memory and mine are in accord.  :-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Deallocating Task objects

[Robert Dewar]

<<It was not declared erroneous in Ada 83.  The ARG defined a new AI
category, "pathological", which said that the question at hand had
nothing to do with anything that could ever be useful in a real program,
and that even if the language gave a definite answer to the question, it
was not useful to write an ACVC test that would force implementors to
degrade their code to conform to that answer.  The later AI simply
reclassified the earlier AI from "binding interpretation" to
"pathological", meaning "Yes, a terminated task can be returned outside
of its master, but it's utterly useless to write a program that does
this, so we don't care if it works right, and we don't want implementors
degrading their implementations to make it work right.">>

said Norman. Right, that's my memory too, note that the really important
idea behind the pathological categorization was to stop the ACVC folks
from generating a test. It was really the ACVC test that damaged the
implementations in this case, not the original ARG ruling itself.

These days, with the new usage oriented viewpoint of the ACVC, such a test
would be unlikely to see the light of day even if the situation had not
been fixed in Ada 95 :-)