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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7343d4a788a9b1a5 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!j33g2000cwa.googlegroups.com!not-for-mail From: "Steve Whalen" Newsgroups: comp.lang.ada Subject: Re: How-to on using the adacl-gc packages Date: 15 May 2006 14:36:33 -0700 Organization: http://groups.google.com Message-ID: <1147728993.560262.232620@j33g2000cwa.googlegroups.com> References: <820e1$44676a08$52ae05e3$31697@news.versatel.net> <1147631169.665365.244810@i40g2000cwc.googlegroups.com> <1147675928.810016.197550@i39g2000cwa.googlegroups.com> NNTP-Posting-Host: 68.238.129.116 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1147728998 10369 127.0.0.1 (15 May 2006 21:36:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 15 May 2006 21:36:38 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: j33g2000cwa.googlegroups.com; posting-host=68.238.129.116; posting-account=GBMmzA0AAABrZ0dHOASa3b2Cdf-RliH9 Xref: g2news2.google.com comp.lang.ada:4270 Date: 2006-05-15T14:36:33-07:00 List-Id: 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