9.1 Task Units and Task Objects

{task declaration} A task unit is declared by a task declaration, which has a corresponding task_body. A task declaration may be a task_type_declaration, in which case it declares a named task type; alternatively, it may be a single_task_declaration, in which case it defines an anonymous task type, as well as declaring a named task object of that type.

Syntax

task_type_declaration ::=
task type defining_identifier [known_discriminant_part] [is task_definition];

single_task_declaration ::=
task defining_identifier [is task_definition];

task_definition ::=
     {task_item}
  [ private
     {task_item}]
  end [task_identifier]

5/1

{8652/0009} task_item ::= entry_declaration | aspect_clause~~representation_clause~~

task_body ::=
   task body defining_identifier is
     declarative_part
   begin
     handled_sequence_of_statements
   end [task_identifier];

If a task_identifier appears at the end of a task_definition or task_body, it shall repeat the defining_identifier.

Legality Rules

{requires a completion (task_declaration}) [partial]} A task declaration requires a completion[, which shall be a task_body,] and every task_body shall be the completion of some task declaration.

8.a

To be honest: The completion can be a pragma Import, if the implementation supports it.

Static Semantics

A task_definition defines a task type and its first subtype. {visible part (of a task unit) [partial]} The first list of task_items of a task_definition, together with the known_discriminant_part, if any, is called the visible part of the task unit. [{private part (of a task unit) [partial]} The optional list of task_items after the reserved word private is called the private part of the task unit.]

9.a

Proof: Private part is defined in Section 8.

9.1/1

{8652/0029} For a task declaration without a task_definition, a task_definition without task_items is assumed.

Dynamic Semantics

[{elaboration (task declaration) [partial]} The elaboration of a task declaration elaborates the task_definition. {elaboration (single_task_declaration) [partial]} The elaboration of a single_task_declaration also creates an object of an (anonymous) task type.]

10.a

Proof: This is redundant with the general rules for the elaboration of a full_type_declaration and an object_declaration.

{elaboration (task_definition) [partial]} [The elaboration of a task_definition creates the task type and its first subtype;] it also includes the elaboration of the entry_declarations in the given order.

12/1

{8652/0009} {initialization (of a task object) [partial]} As part of the initialization of a task object, any aspect_clauses~~representation_clauses~~ and any per-object constraints associated with entry_declarations of the corresponding task_definition are elaborated in the given order.

12.a/1

Reason: The only aspect_clauses~~representation_clauses~~ defined for task entries are ones that specify the Address of an entry, as part of defining an interrupt entry. These clearly need to be elaborated per-object, not per-type. Normally the address will be a function of a discriminant, if such an Address clause is in a task type rather than a single task declaration, though it could rely on a parameterless function that allocates sequential interrupt vectors.

12.b

We do not mention representation pragmas, since each pragma may have its own elaboration rules.

{elaboration (task_body) [partial]} The elaboration of a task_body has no effect other than to establish that tasks of the type can from then on be activated without failing the Elaboration_Check.

[The execution of a task_body is invoked by the activation of a task of the corresponding type (see 9.2).]

The content of a task object of a given task type includes:

The values of the discriminants of the task object, if any;

An entry queue for each entry of the task object;

17.a

Ramification: "For each entry" implies one queue for each single entry, plus one for each entry of each entry family.

A representation of the state of the associated task.

NOTES

2 Within the declaration or body of a task unit, the name of the task unit denotes the current instance of the unit (see 8.6), rather than the first subtype of the corresponding task type (and thus the name cannot be used as a subtype_mark).

19.a

Discussion: However, it is possible to refer to some other subtype of the task type within its body, presuming such a subtype has been declared between the task_type_declaration and the task_body.

3 The notation of a selected_component can be used to denote a discriminant of a task (see 4.1.3). Within a task unit, the name of a discriminant of the task type denotes the corresponding discriminant of the current instance of the unit.

4 A task type is a limited type (see 7.5), and hence has neither an assignment operation nor predefined equality operators. If an application needs to store and exchange task identities, it can do so by defining an access type designating the corresponding task objects and by using access values for identification purposes. Assignment is available for such an access type as for any access type. Alternatively, if the implementation supports the Systems Programming Annex, the Identity attribute can be used for task identification (see C.7).

Examples

Examples of declarations of task types:

task type Server is entry Next_Work_Item(WI : in Work_Item); entry Shut_Down; end Server;

task type Keyboard_Driver(ID : Keyboard_ID := New_ID) is entry Read (C : out Character); entry Write(C : in Character); end Keyboard_Driver;

Examples of declarations of single tasks:

task Controller is entry Request(Level)(D : Item); -- a family of entries end Controller;

task Parser is entry Next_Lexeme(L : in Lexical_Element); entry Next_Action(A : out Parser_Action); end;

task User; -- has no entries

Examples of task objects:

Agent : Server; Teletype : Keyboard_Driver(TTY_ID); Pool : array(1 .. 10) of Keyboard_Driver;

Example of access type designating task objects:

type Keyboard is access Keyboard_Driver; Terminal : Keyboard := new Keyboard_Driver(Term_ID);

Extensions to Ada 83

32.a/1

{extensions to Ada 83} The syntax rules for task declarations are modified to allow a known_discriminant_part, and to allow a private part. They are also modified to allow entry_declarations and aspect_clauses~~representation_clauses~~ to be mixed.

Wording Changes from Ada 83

32.b

The syntax rules for tasks have been split up according to task types and single tasks. In particular: The syntax rules for task_declaration and task_specification are removed. The syntax rules for task_type_declaration, single_task_declaration, task_definition and task_item are new.

32.c

The syntax rule for task_body now uses the nonterminal handled_sequence_of_statements.

32.d

The declarative_part of a task_body is now required; that doesn't make any real difference, because a declarative_part can be empty.

Contents Index Previous Next Legal