next up previous contents index
Next: GNAT Implementation Up: Abortion Previous: Abortion   Contents   Index

Subsections


Ada Abortion


Abort Statement

The abort statement is intended for use in response to those error conditions where recovery by the errant task is deemed to be impossible. Tasks which are aborted are said to become abnormal, and are thus prevented from interacting with any other task. Ideally, an abnormal task will stop executing immediately. However, some implementations may not be able to facilitate immediate shut-down, and hence the ARM [AAR95, section 9.8] requires is that the task terminate before it next interacts with other tasks [BW98, section 10.2]. The syntax of the abort statement is:

   abort_statement ::= abort task_name {, task_name};

Each aborted task becomes abnormal and any non-completed tasks that depend upon an aborted task also become abnormal. Once all named tasks are marked as abnormal, then the abort statement is complete, and the task executing the abort can continue. It does not wait until named tasks have actually terminated [BW98, section 10.2].

After a task has been marked as abnormal, execution of its body is aborted. This means that the execution of every construct in the task body is aborted, unless it is involved in the execution of an abort deferred operation. The execution of an abort-deferred operation is allowed to complete before it is aborted [BW98, section 10.2].

If a construct which has been aborted is blocked outside an abort-deferred operation (other than at an entry call), the construct becomes abnormal and is immediately completed. Other constructs must complete no later than the next abort completion point (if any) that occurs outside an abort-deferred operation. These are [BW98, section 10.2]:

Certain actions must be protected in order that the integrity of the remaining tasks and their data be assured. The following operations are defined to be abort-deferred [BW98, section 10.2.1]:


Asynchronous Transfer of Control

The asynchronous transfer of control allows the caller to continue executing some code while the entry call is waiting to be attended. The syntax is [AAR95, section 9.7.4]:

   asynchronous_select ::=
     select
       triggering_alternative
     then abort
       abortable_part
     end select;

   triggering_alternative ::=
       triggering_statement
       [sequence_of_statements]

   triggering_statement ::=
       entry_call_statement
     | delay_statement

   abortable_part ::= sequence_of_statements

If the triggering statement is queued (due to an entry call statement or to a delay statement) the abortable part starts its concurrent execution. When one of the parts finishes its execution it aborts the execution of the other part. This provides local abortion which is potentially cheaper than the abortion of the entire task.

There is a restriction on the sequence of statements that can appear in the abortable part. It must not contain an accept statement. The reason for this is to keep the implementation as simple as possible [BW98, section 10.3.2].

The asynchronous select statement can be nested. The abortable part may itself contain another asynchronous select statement. In this case, the ATC may have to propagate to an outer asynchronous select scope if its triggering statement completes. In the process, all inner asynchronous select statements have to be aborted [GMB93, section 4.1].


next up previous contents index
Next: GNAT Implementation Up: Abortion Previous: Abortion   Contents   Index
(c) Javier Miranda. Canary Islands (Spain), 2002. Version 1.0