Re: Dynamic allocation of tasks

[Robert A Duff <bobduff@world.std.com>]

Florian Weimer <fw@deneb.cygnus.argh.org> 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