Ada Reference Manual (Ada 2022) — Legal Information
Contents   Index   References   Search   Previous   Next 

9.5 Intertask Communication

1
The primary means for intertask communication is provided by calls on entries and protected subprograms. Calls on protected subprograms allow coordinated access to shared data objects. Entry calls allow for blocking the caller until a given condition is satisfied (namely, that the corresponding entry is open — see 9.5.3), and then communicating data or control information directly with another task or indirectly via a shared protected object.

Static Semantics

2/3
When a name or prefix denotes an entry, protected subprogram, or a prefixed view of a primitive subprogram of a limited interface whose first parameter is a controlling parameter, the name or prefix determines a target object, as follows: 
3/3
If it is a direct_name or expanded name that denotes the declaration (or body) of the operation, then the target object is implicitly specified to be the current instance of the task or protected unit immediately enclosing the operation; a call using such a name is defined to be an internal call;
4/3
If it is a selected_component that is not an expanded name, then the target object is explicitly specified to be the object denoted by the prefix of the name; a call using such a name is defined to be an external call; 
5/3
If the name or prefix is a dereference (implicit or explicit) of an access-to-protected-subprogram value, then the target object is determined by the prefix of the Access attribute_reference that produced the access value originally; a call using such a name is defined to be an external call;
6
If the name or prefix denotes a subprogram_renaming_declaration, then the target object is as determined by the name of the renamed entity.
6.1/3
 A call on an entry or a protected subprogram either uses a name or prefix that determines a target object implicitly, as above, or is a call on (a non-prefixed view of) a primitive subprogram of a limited interface whose first parameter is a controlling parameter, in which case the target object is identified explicitly by the first parameter. This latter case is an external call.
7
A corresponding definition of target object applies to a requeue_statement (see 9.5.4), with a corresponding distinction between an internal requeue and an external requeue.

Legality Rules

7.1/3
 If a name or prefix determines a target object, and the name denotes a protected entry or procedure, then the target object shall be a variable, unless the prefix is for an attribute_reference to the Count attribute (see 9.9). 
7.2/5
 An internal call on a protected function shall not occur within a precondition expression (see 6.1.1) of a protected operation nor within a default_expression of a parameter_specification of a protected operation.

Dynamic Semantics

8
Within the body of a protected operation, the current instance (see 8.6) of the immediately enclosing protected unit is determined by the target object specified (implicitly or explicitly) in the call (or requeue) on the protected operation. 
9
Any call on a protected procedure or entry of a target protected object is defined to be an update to the object, as is a requeue on such an entry. 

Syntax

10/3
synchronization_kind ::= By_Entry | By_Protected_Procedure | Optional

Static Semantics

11/3
For the declaration of a primitive procedure of a synchronized tagged type the following language-defined representation aspect may be specified with an aspect_specification (see 13.1.1):
12/3
Synchronization

If specified, the aspect definition shall be a synchronization_kind.
13/3
Inherited subprograms inherit the Synchronization aspect, if any, from the corresponding subprogram of the parent or progenitor type. If an overriding operation does not have a directly specified Synchronization aspect then the Synchronization aspect of the inherited operation is inherited by the overriding operation. 

Legality Rules

14/3
The synchronization_kind By_Protected_Procedure shall not be applied to a primitive procedure of a task interface.
15/3
A procedure for which the specified synchronization_kind is By_Entry shall be implemented by an entry. A procedure for which the specified synchronization_kind is By_Protected_Procedure shall be implemented by a protected procedure. A procedure for which the specified synchronization_kind is Optional may be implemented by an entry or by a procedure (including a protected procedure).
16/3
If a primitive procedure overrides an inherited operation for which the Synchronization aspect has been specified to be By_Entry or By_Protected_Procedure, then any specification of the aspect Synchronization applied to the overriding operation shall have the same synchronization_kind.
17/3
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. 

Static Semantics

18/5
For a program unit, task entry, formal package, formal subprogram, formal object of an anonymous access-to-subprogram type, enumeration literal, and for a subtype (including a formal subtype), the following language-defined operational aspect is defined:
19/5
Nonblocking
This aspect specifies the blocking restriction for the entity; it shall be specified by a static Boolean expression. The aspect_definition can be omitted from the specification of this aspect; in that case, the aspect for the entity is True.
20/5
The Nonblocking aspect may be specified for all entities for which it is defined, except for protected operations and task entries. In particular, Nonblocking may be specified for generic formal parameters.
21/5
When aspect Nonblocking is False for an entity, the entity can contain a potentially blocking operation; such an entity allows blocking. If the aspect is True for an entity, the entity is said to be nonblocking.
22/5
For a generic instantiation and entities declared within such an instance, the aspect is determined by the Nonblocking aspect for the corresponding entity of the generic unit, anded with the Nonblocking aspects of the actual generic parameters used by the entity. If the aspect is directly specified for an instance, the specified expression shall have the same value as the Nonblocking aspect of the instance (after anding with the aspects of the used actual parameters). In the absence of a Use_Formal aspect, all actual generic parameters are presumed to be used by an entity (see H.7.1).
23/5
For a (protected or task) entry, the Nonblocking aspect is False.
24/5
For an enumeration literal, the Nonblocking aspect is True.
25/5
For a predefined operator of an elementary type, the Nonblocking aspect is True. For a predefined operator of a composite type, the Nonblocking aspect of the operator is the same as the Nonblocking aspect for the type.
26/5
For a dereference of an access-to-subprogram type, the Nonblocking aspect of the designated subprogram is that of the access-to-subprogram type.
27/5
For the base subtype of a scalar (sub)type, the Nonblocking aspect is True.
28/5
For an inherited primitive dispatching subprogram that is null or abstract, the subprogram is nonblocking if and only if a corresponding subprogram of at least one ancestor is nonblocking. For any other inherited subprogram, it is nonblocking if and only if the corresponding subprogram of the parent is nonblocking.
29/5
Unless directly specified, overridings of dispatching operations inherit this aspect.
30/5
Unless directly specified, for a formal subtype, formal package, or formal subprogram, the Nonblocking aspect is that of the actual subtype, package, or subprogram.
31/5
Unless directly specified, for a non-first subtype S, the Nonblocking aspect is that of the subtype identified in the subtype_indication defining S; unless directly specified for the first subtype of a derived type, the Nonblocking aspect is that of the ancestor subtype.
32/5
Unless directly specified, for any other program unit, first subtype, or formal object, the Nonblocking aspect of the entity is determined by the Nonblocking aspect for the innermost program unit enclosing the entity.
33/5
If not specified for a library unit, the Nonblocking aspect is True if the library unit is declared pure, or False otherwise.
34/5
The following are defined to be potentially blocking operations:
35/5
a select_statement;
36/5
an accept_statement;
37/5
an entry_call_statement, or a call on a procedure that renames or is implemented by an entry;
38/5
a delay_statement;
39/5
an abort_statement;
40/5
task creation or activation;
41/5
during a protected action, an external call on a protected subprogram (or an external requeue) with the same target object as that of the protected action.
42/5
If a language-defined subprogram allows blocking, then a call on the subprogram is a potentially blocking operation.

Legality Rules

43/5
A portion of program text is called a nonblocking region if it is anywhere within a parallel construct, or if the innermost enclosing program unit is nonblocking. A nonblocking region shall not contain any of the following:
44/5
a select_statement;
45/5
an accept_statement;
46/5
a delay_statement;
47/5
an abort_statement;
48/5
task creation or activation. 
49/5
Furthermore, a parallel construct shall neither contain a call on a callable entity for which the Nonblocking aspect is False, nor shall it contain a call on a callable entity declared within a generic unit that uses a generic formal parameter with Nonblocking aspect False (see Use_Formal aspect in H.7.1).
50/5
Finally, a nonblocking region that is outside of a parallel construct shall not contain a call on a callable entity for which the Nonblocking aspect is False, unless the region is within a generic unit and the callable entity is associated with a generic formal parameter of the generic unit, or the call is within the aspect_definition of an assertion aspect for an entity that allows blocking.
51/5
For the purposes of the above rules, an entry_body is considered nonblocking if the immediately enclosing protected unit is nonblocking.
52/5
For a subtype for which aspect Nonblocking is True, any predicate expression that applies to the subtype shall only contain constructs that are allowed immediately within a nonblocking program unit.
53/5
A subprogram shall be nonblocking if it overrides a nonblocking dispatching operation. An entry shall not implement a nonblocking procedure. If an inherited dispatching subprogram allows blocking, then the corresponding subprogram of each ancestor shall allow blocking.
54/5
It is illegal to directly specify aspect Nonblocking for the first subtype of the full view of a type that has a partial view. If the Nonblocking aspect of the full view is inherited, it shall have the same value as that of the partial view, or have the value True.
55/5
Aspect Nonblocking shall be directly specified for the first subtype of a derived type only if it has the same value as the Nonblocking aspect of the ancestor subtype or if it is specified True. Aspect Nonblocking shall be directly specified for a nonfirst subtype S only if it has the same value as the Nonblocking aspect of the subtype identified in the subtype_indication defining S or if it is specified True.
56/5
For an access-to-object type that is nonblocking, the Allocate, Deallocate, and Storage_Size operations on its storage pool shall be nonblocking.
57/5
For a composite type that is nonblocking:
58/5
All component subtypes shall be nonblocking;
59/5
For a record type or extension, every call in the default_expression of a component (including discriminants) shall call an operation that is nonblocking;
60/5
For a controlled type, the Initialize, Finalize, and Adjust (if any) subprograms shall be nonblocking.
61/5
The predefined equality operator for a composite type, unless it is for a record type or record extension and the operator is overridden by a primitive equality operator, is illegal if it is nonblocking and:
62/5
for a record type or record extension, the parent primitive "=" allows blocking; or
63/5
some component is of a type T, and:
64/5
T is a record type or record extension that has a primitive "=" that allows blocking; or
65/5
T is neither a record type nor a record extension, and T has a predefined "=" that allows blocking. 
66/5
In a generic instantiation:
67/5
the actual subprogram corresponding to a nonblocking formal subprogram shall be nonblocking (an actual that is an entry is not permitted in this case);
68/5
the actual subtype corresponding to a nonblocking formal subtype shall be nonblocking;
69/5
the actual object corresponding to a formal object of a nonblocking access-to-subprogram type shall be of a nonblocking access-to-subprogram type;
70/5
the actual instance corresponding to a nonblocking formal package shall be nonblocking.
71/5
In addition to the places where Legality Rules normally apply (see 12.3), the above rules also apply in the private part of an instance of a generic unit.
72/3
NOTE   The synchronization_kind By_Protected_Procedure implies that the operation will not block. 
Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe