Contents Index Previous Next
C.7.2 The Package Task_Attributes
Static Semantics
1
The following language-defined
generic library package exists:
2
with Ada.Task_Identification; use Ada.Task_Identification;
generic
type Attribute is private;
Initial_Value : in Attribute;
package Ada.Task_Attributes is
3
type Attribute_Handle is access all Attribute;
4
function Value(T : Task_ID := Current_Task)
return Attribute;
5
function Reference(T : Task_ID := Current_Task)
return Attribute_Handle;
6
procedure Set_Value(Val : in Attribute;
T : in Task_ID := Current_Task);
procedure Reinitialize(T : in Task_ID := Current_Task);
7
end Ada.Task_Attributes;
Dynamic Semantics
8
When an instance of Task_Attributes is elaborated
in a given active partition, an object of the actual type corresponding
to the formal type Attribute is implicitly created for each task (of
that partition) that exists and is not yet terminated. This object acts
as a user-defined attribute of the task. A task created previously in
the partition and not yet terminated has this attribute from that point
on. Each task subsequently created in the partition will have this attribute
when created. In all these cases, the initial value of the given attribute
is Initial_Value.
9
The Value operation returns the value of the corresponding
attribute of T.
10
The Reference operation returns an access value
that designates the corresponding attribute of T.
11
The Set_Value operation performs any
finalization on the old value of the attribute of T and assigns Val to that
attribute (see
5.2 and
7.6).
12
The effect of the Reinitialize operation is the
same as Set_Value where the Val parameter is replaced with Initial_Value.
12.a
Implementation Note: In
most cases, the attribute memory can be reclaimed at this point.
13
{Tasking_Error (raised by failure
of run-time check)} For all the operations
declared in this package, Tasking_Error is raised if the task identified
by T is terminated.
{Program_Error (raised by failure
of run-time check)} Program_Error is raised
if the value of T is Null_Task_ID.
Bounded (Run-Time) Errors
13.1/1
{
8652/0071}
{bounded error (cause) [partial]} If
the package Ada.Task_Attributes is instantiated with a controlled type and the
controlled type has user-defined Adjust or Finalize operations that in turn
access task attributes by any of the above operations, then a call of Set_Value
of the instantiated package constitutes a bounded error. The call may perform
as expected or may result in forever blocking the calling task and subsequently
some or all tasks of the partition.
Erroneous Execution
14
{erroneous execution (cause)
[partial]} It is erroneous to dereference
the access value returned by a given call on Reference after a subsequent
call on Reinitialize for the same task attribute, or after the associated
task terminates.
14.a
Reason: This allows the
storage to be reclaimed for the object associated with an attribute upon
Reinitialize or task termination.
15
{erroneous execution (cause)
[partial]} If a value of Task_ID is passed
as a parameter to any of the operations declared in this package and
the corresponding task object no longer exists, the execution of the
program is erroneous.
15.1/1
{
8652/0071}
{erroneous execution (cause) [partial]} Accesses
to task attributes via a value of type Attribute_Handle are erroneous if executed
concurrently with each other or with calls of any of the operations declared
in package Task_Attributes.
15.a.1/1
Reason: There is no
requirement of atomicity on accesses via a value of type Attribute_Handle.
Implementation Requirements
16/1
{
8652/0071}
For a given attribute of a given task, tThe implementation shall
perform
the operations declared in this packageeach of the above operations
for a given attribute of a given task atomically with respect to any
of
these operations ofother of the above operations for the same attribute
of the same task.
The granularity of any locking mechanism necessary to achieve
such atomicity is implementation defined.
16.a.1/1
Implementation defined: Granularity
of locking for Task_Attributes.
16.a
Ramification: Hence, other
than by dereferencing an access value returned by Reference, an attribute
of a given task can be safely read and updated concurrently by multiple
tasks.
17
When a task terminates, the implementation shall
finalize all attributes of the task, and reclaim any other storage associated
with the attributes.
Documentation Requirements
18
The implementation shall document the limit on
the number of attributes per task, if any, and the limit on the total
storage for attribute values per task, if such a limit exists.
19
In addition, if these limits can be configured,
the implementation shall document how to configure them.
19.a/1
Implementation defined: Limits
on the number and size of task attributes, and how to configure them.Implementation-defined
aspects of Task_Attributes.
Metrics
20
The implementation shall document the following
metrics: A task calling the following subprograms shall execute in a
sufficiently high priority as to not be preempted during the measurement
period. This period shall start just before issuing the call and end
just after the call completes. If the attributes of task T are accessed
by the measurement tests, no other task shall access attributes of that
task during the measurement period. For all measurements described here,
the Attribute type shall be a scalar whose size is equal to the size
of the predefined integer size. For each measurement, two cases shall
be documented: one where the accessed attributes are of the calling task
[(that is, the default value for the T parameter is used)], and the other,
where T identifies another, non-terminated, task.
21
The following calls
(to subprograms in the Task_Attributes package) shall be measured:
22
- a call to Value, where the return value is Initial_Value;
23
- a call to Value, where the return value is not equal to
Initial_Value;
24
- a call to Reference, where the return value designates
a value equal to Initial_Value;
25
- a call to Reference, where the return value designates
a value not equal to Initial_Value;
26
- a call to Set_Value where the Val parameter is not equal
to Initial_Value and the old attribute value is equal to Initial_Value.
27
- a call to Set_Value where the Val parameter is not equal
to Initial_Value and the old attribute value is not equal to Initial_Value.
Implementation Permissions
28
An implementation need not actually create the
object corresponding to a task attribute until its value is set to something
other than that of Initial_Value, or until Reference is called for the
task attribute. Similarly, when the value of the attribute is to be reinitialized
to that of Initial_Value, the object may instead be finalized and its
storage reclaimed, to be recreated when needed later. While the object
does not exist, the function Value may simply return Initial_Value, rather
than implicitly creating the object.
28.a
Discussion: The effect
of this permission can only be observed if the assignment operation for
the corresponding type has side-effects.
28.b
Implementation Note: This
permission means that even though every task has every attribute, storage
need only be allocated for those attributes that have been Reference'd
or set to a value other than that of Initial_Value.
29
An implementation is allowed to place restrictions
on the maximum number of attributes a task may have, the maximum size
of each attribute, and the total storage size allocated for all the attributes
of a task.
Implementation Advice
30
Some implementations are targeted to domains
in which memory use at run time must be completely deterministic. For
such implementations, it is recommended that the storage for task attributes
will be pre-allocated statically and not from the heap. This can be accomplished
by either placing restrictions on the number and the size of the task's
attributes, or by using the pre-allocated storage for the first N attribute
objects, and the heap for the others. In the latter case, N should be
documented.
31
12 An attribute always exists
(after instantiation), and has the initial value. It need not occupy
memory until the first operation that potentially changes the attribute
value. The same holds true after Reinitialize.
32
13 The result of the Reference
function should be used with care; it is always safe to use that result
in the task body whose attribute is being accessed. However, when the
result is being used by another task, the programmer must make sure that
the task whose attribute is being accessed is not yet terminated. Failing
to do so could make the program execution erroneous.
33
14 As specified in C.7.1,
if the parameter T (in a call on a subprogram of an instance of this package)
identifies a nonexistent task, the execution of the program is erroneous.
Contents Index Previous Next Legal