9.1 Task Units and Task Objects

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.

For a task declaration with an interface_list,
the task type inherits user-defined primitive subprograms from each progenitor
type (see 3.9.4), in the same way that a
derived type inherits user-defined primitive subprograms from its progenitor
types (see 3.4). If the first parameter of
a primitive inherited subprogram is of the task type or an access parameter
designating the task type, and there is an entry_declaration
for a single entry with the same identifier within the task declaration,
whose profile is type conformant with the prefixed view profile of the
inherited subprogram, the inherited subprogram is said to be implemented
by the conforming task entry using an implicitly declared nonabstract
subprogram which has the same profile as the inherited subprogram and
which overrides it.

The prefixed view profile of an explicitly declared
primitive subprogram of a tagged task type shall not be type conformant
with any entry of the task type, if the subprogram has the same defining
name as the entry and the first parameter of the subprogram is of the
task type or is an access parameter designating the task type.

the inherited subprogram is overridden with a primitive
subprogram of the task type, in which case the overriding subprogram
shall be subtype conformant with the inherited subprogram and not abstract;
or

If neither applies, the inherited subprogram shall
be a null procedure. In addition to the places where
Legality Rules normally apply (see 12.3),
these rules also apply in the private part of an instance of a generic
unit.

2 Other than in an access_definition,
the name of a task unit within the declaration or body 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).

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 precludes use of assignment_statements
and 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.1).