From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,89cbee942992178a X-Google-Attributes: gid103376,public From: Mats Weber Subject: Re: Deallocating Task objects Date: 1997/02/17 Message-ID: <33086C65.F9F@elca-matrix.ch>#1/1 X-Deja-AN: 219469742 References: <01bc1b53$fb0251c0$829d6482@joy.ericsson.se> Content-Type: text/plain; charset=us-ascii Organization: ELCA Matrix SA Mime-Version: 1.0 Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) Date: 1997-02-17T00:00:00+00:00 List-Id: 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.