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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1583af5ff29435e5 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Dynamic allocation of tasks Date: 2000/03/27 Message-ID: #1/1 X-Deja-AN: 603147790 Sender: bobduff@world.std.com (Robert A Duff) References: <87r9d3gvix.fsf@deneb.cygnus.argh.org> <8basg1$627$1@nnrp1.deja.com> <87ya7aewb8.fsf@deneb.cygnus.argh.org> <874s9yd6s2.fsf@deneb.cygnus.argh.org> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-03-27T00:00:00+00:00 List-Id: Florian Weimer writes: > In my last posting, I have failed to mention a piece of information which > might be important: after an "abort Some_Task;", "Some_Task'Terminated' > never became true (even if I waited three or five seconds before > examining the attribute). In fact, this motivated my first RM > interpretation that an abnormal task is not a terminated task. That's correct -- abnormal is not the same thing as terminated. An "abort T;" says, more or less, "Dear T, please start aborting yourself when you get around to it." When the abort statement is over, the aborting task doesn't know much of anything about the status of T. I didn't see your exact program, so I don't know what's going on. Perhaps you have a higher priority task running, which prevents the abortee from running, so it never gets around to terminating itself? Maybe the higher priority task was the one doing the abort? In Ada, especially Ada 95, the way the run-time system normally does aborts is that the abortee does the work. The aborter sends some sort of message to the abortee, and the abortee then does something that's a lot like raising an exception. This causes local variables to be finalized, and eventually terminates the task. But the task has to run for that to happen, which means that it has to be the highest priority task at some point (assuming a single CPU). Another point is that if the abortee doesn't do certain things (such as entry calls), then it might *never* notice that it is abnormal. Unless the implementation supports the real-time annex, where the rules are more stringent. >... (No, > compiler behavior does not determine my RM interpretations, but it > suggest the direction in which I search for evidence. ;-) - Bob