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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ea9fbf0f08e5af8a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!novia!news-out.readnews.com!transit4.readnews.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Delayed deallocation of non-terminated task in Gnat? Date: Wed, 31 Aug 2011 17:09:47 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <31ba531d-fa8e-40f3-97bc-c9112b329fe2@14g2000prv.googlegroups.com> <1k4finucoux98.7be4jx6iy5kx$.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls6.std.com 1314824987 25546 192.74.137.71 (31 Aug 2011 21:09:47 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 31 Aug 2011 21:09:47 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:MFLDgOt3rl+VogFKgp0jHw4KBoM= Xref: g2news2.google.com comp.lang.ada:21773 Date: 2011-08-31T17:09:47-04:00 List-Id: "J-P. Rosen" writes: > Le 31/08/2011 20:12, Robert A Duff a �crit : >> I consider it a flaw in Ada that there's no general-purpose >> way to block waiting for the termination of a task. >> > With some cooperation of the other task... > > Declare in the waited task an entry (Wait_For_Terminate) which is never > accepted. The waiting task calls the entry, and gets Tasking_Error when > the waited task terminates (for whatever reason). We thought of that while implementing the feature that started this thread. Unfortunately, it doesn't quite work. The Tasking_Error is raised when the task is completed, so at the time T_E is handled, the other task could still be going about its business doing finalization. And even if there's no user-level finalization involved, there's still some stuff going on in the run-time system between completion and termination. So there's an inherent race condition here. What I claim is missing from Ada (and is hard to implement) is a feature that blocks a task until some other task(s) is/are really and truly terminated, and won't execute a single 'nother instruction. You can loop, checking 'Terminated, with a delay. But the delay is guaranteed to be either too long or too short -- most likely both. The feature we're talking about was implemented because there was such a loop, and it was causing an AdaCore customer's program (with thousands of dynamically allocated tasks) to take half an hour. After implementing this feature, and removing the loop-with-delay, it took a few seconds. - Bob