9.10. Abort Statements

[PREVIOUS][UP][NEXT]

An abort statement causes one or more tasks to become abnormal, thus preventing any further rendezvous with such tasks.

    abort_statement ::= abort task_name {, task_name}; 

The determination of the type of each task name uses the fact that the type of the name is a task type.

For the execution of an abort statement, the given task names are evaluated in some order that is not defined by the language. Each named task then becomes abnormal unless it is already terminated; similarly, any task that depends on a named task becomes abnormal unless it is already terminated.

Any abnormal task whose execution is suspended at an accept statement, a select statement, or a delay statement becomes completed; any abnormal task whose execution is suspended at an entry call, and that is not yet in a corresponding rendezvous, becomes completed and is removed from the entry queue; any abnormal task that has not yet started its activation becomes completed (and hence also terminated). This completes the execution of the abort statement.

The completion of any other abnormal task need not happen before completion of the abort statement. It must happen no later than when the abnormal task reaches a synchronization point that is one of the following: the end of its activation; a point where it causes the activation of another task; an entry call; the start or the end of an accept statement; a select statement; a delay statement; an exception handler; or an abort statement. If a task that calls an entry becomes abnormal while in a rendezvous, its termination does not take place before the completion of the rendezvous (see 11.5).

The call of an entry of an abnormal task raises the exception TASKING_ERROR at the place of the call. Similarly, the exception TASKING_ERROR is raised for any task that has called an entry of an abnormal task, if the entry call is still queued or if the rendezvous is not yet finished (whether the entry call is an entry call statement, or a conditional or timed entry call); the exception is raised no later than the completion of the abnormal task. The value of the attribute CALLABLE is FALSE for any task that is abnormal (or completed).

If the abnormal completion of a task takes place while the task updates a variable, then the value of this variable is undefined. Example:

    abort USER, TERMINAL.all, POOL(3); 

Notes:

An abort statement should be used only in extremely severe situations requiring unconditional termination. A task is allowed to abort any task, including itself.

References: abnormal in rendezvous, accept statement, activation, attribute, callable (predefined attribute), conditional entry call, delay statement, dependent task, entry call statement, evaluation of a name, exception handler, false boolean value, name, queue of entry calls, rendezvous, select statement, statement, task, tasking_error exception, terminated task, timed entry call.


[INDEX][CONTENTS]