CVS difference for ais/ai-00237.txt
--- ais/ai-00237.txt 2002/10/29 20:24:57 1.12
+++ ais/ai-00237.txt 2003/09/18 22:42:53 1.13
@@ -1,4 +1,8 @@
-!standard C.07.02 (17) 01-09-11 AI95-00237/05
+!standard C.07.01 (17) 03-09-17 AI95-00237/06
+!standard C.07.02 (13)
+!standard C.07.02 (15.1/1)
+!standard C.07.02 (17)
+!standard C.07.02 (30)
!class binding interpretation 00-05-31
!status work item 01-10-05
!status ARG approved 8-0-0 01-05-20
@@ -11,14 +15,20 @@
!summary
+After a task terminates, all of its task attributes are finalized.
The master of task attributes is the master of the instantiation of
-Ada.Task_Attributes that creates them. Task attributes can be finalized
-at any point after their task is terminated and no later than the completion
-of the master of the instantiation of Ada.Task_Attributes that created them.
+Ada.Task_Attributes that creates them. At the time when the master of
+such an instantiation is finalized, any remaining non-finalized
+task attributes created by the instantiation are finalized.
+
+Implementation advice is added to perform the finalization of task
+attributes and reclamation of associated memory as soon as possible
+after task termination.
+
+The race condition arising from the completion of the master and
+concurrent access to the task attributes as well as access to
+attributes thus finalized is declared erroneous.
-It is a bounded error to call Ada.Task_Identification.Current_Task during the
-finalization of a task attribute.
-
!question
C.7.2(17) says:
@@ -39,71 +49,79 @@
!wording
Add the following after C.7.2(13):
- When the master of an instantiation of Ada.Task_Attributes is finalized,
- the corresponding attribute of each task is finalized.
-
-Delete C.7.2(17).
-
-Add the following after C.7.2(28):
- If the task terminates before the master of the instantiation of
- Task_Attributes is finalized, an implementation may finalize the object
- corresponding to the attribute of the task at this time (instead of when
- the master of the instantiation is finalized), and reclaim any other
- storage associated with the attribute.
+ After a task has terminated, all of its attributes are finalized,
+ unless they have been finalized earlier. When the master of an
+ instantiation of Ada.Task_Attributes is finalized, the
+ corresponding attribute of each task is finalized, unless it has
+ been finalized earlier.
+
+Extend C.7.2 (15.1/1) as follows:
+ Access to a task attribute is erroneous if executed concurrently with
+ or after the finalization of the task attribute.
+
+Change C.7.2(17) to read:
+ After task attributes are finalized, the implementation shall reclaim any
+ storage associated with the attributes.
+
+Add the following before (or after) C.7.2(30):
+ Finalization of task attributes and reclamation of associated storage
+ should be performed as soon as possible after task termination.
-Add "finalization of a task attribute" to C.7.1(17).
+Add "finalization of a task attribute" to C.7.1(17), 1. sentence.
!discussion
-Although it is not clear from the standard, it is not possible in general
-for a task to finalize its own attributes. This is because a task that is never
-activated may have attributes that require finalization.
-
-However, this begs the question: if a task owning attributes cannot finalize
-them, what task can? One way to attempt to answer the question is to determine
-the master of the attributes. (After all, for ordinary objects, it is the
-master that determines when they are finalized.) However, the standard does not
-address this at all.
-
It is clear that the task attributes should not exist any longer than the
instantiation that created them. If they do exist past that point, there is the
risk that their type is also no longer accessible, and that the finalization
-may depend on entities that no longer exist. Therefore, we declare that the
-master of the instantiation is the master of the task attributes.
+may depend on entities that no longer exist.
-This gives a clear point by which the finalization of attributes must have
-completed: the completion of the master which contains the instantiation.
-Once we have this clear point, we no longer need the (now) conflicting rule
-that says that the attributes are finalized when their task terminates.
-Moreover, this rule complicates implementation of task attributes, requiring
-an interaction between the attributes package and the task supervisor upon
-task termination. This can be difficult to accomplish when Ada tasking is
-built on top of an existing operating systems threading mechanisms.
-
-Therefore, we convert this rule to an implementation permission, allowing
-finalization at any point after a task terminates. We leave it as an
-implementation permission (rather than deleting it outright) for three reasons:
- * So that existing implementations need not be changed;
- * So that storage can be recovered when a task terminates. For long-running
- applications which dynamically create tasks, this storage can be
- significant;
- * So that attributes can be implemented as a property of a task (say, as
- space in a task control block [TCB]). In order to support that, we have
- to be able to finalize attributes when task data structures are freed.
-
-An implementation taking advantage of this permission must insure that only
-a single task finalizes the attributes. (It is possible for a task to terminate
-at the same time that the master containing the instantation is left. It must
-never be the case that both tasks finalize the attributes.)
-
-It is important that attributes are not finalized before task termination,
-because they can be accessed until T'Terminated becomes True. We do not want
-to be able to access finalized task attributes.
+This gives a clear point by which the finalization of task attributes
+must have completed: the completion of the master which contains the
+instantiation. This point may be earlier than the termination of the
+affected tasks (a situation ignored by current wording of C.7.2).
+
+However, as many task attributes are likely to be created at library
+level, postponing task attribute finalization and storage reclamation
+in general to the completion of their master would imply that task
+attributes are only reclaimed upon program termination. This behavior
+is clearly undesirable (and unreasonable, if implementations chose to
+reserve attribute storage within task control blocks).
+
+Hence task attributes should also be finalized and storage be reclaimed upon
+task termination.
+
+The wording of C.7.2(17), "When a task terminates, the implementation
+shall finalize all attributes of the task..." is imprecise and creates
+a race condition as noted in the 2nd !question. Moreover, it should be
+noted that it is not possible in general for a task to finalize its
+own attributes. This is because a task that is never activated may
+have attributes that require finalization.
+
+To tie the finalization of attributes too closely to the termination
+of tasks may create implementation difficulties, since it requires an
+interaction between the attributes package and the task supervisor
+upon task termination. This can be difficult to accomplish when Ada
+tasking is built on top of an existing operating systems threading
+mechanism.
+
+Hence we decided to change the wording to "After a task terminates,...."
+and to add Implementation Advice that finalization and storage reclamation
+should happen as soon as possible after task termination.
+
+By making clear that the task is terminated first, the race condition
+upon task termination disappears as other rules already take care of
+attribute accesses on terminated tasks. It remains to clarify the
+semantics of accesses to attributes that are concurrent with (or
+after) the finalization due to completion of their master. Here, we
+opt for erroneousness rather than a requirement for atomicity for the
+reasons stated above plus some means to record the early disappearance
+of the attribute.
Since we do not define which task finalizes the attributes (or even if it is
a real task), we make the use of Current_Task in the Finalize routine of a
-task attribute a bounded error.
+task attribute a bounded error and amend C.7.1(17) accordingly.
!corrigendum C.7.1(17)
@@ -124,31 +142,47 @@
the task identified by T is terminated. Program_Error is raised if the value
of T is Null_Task_ID.
@dinst
-When the master of an instantiation of Ada.Task_Attributes is finalized,
-the corresponding attribute of each task is finalized.
+After a task has terminated, all of its attributes are finalized,
+unless they have been finalized earlier. When the master of an
+instantiation of Ada.Task_Attributes is finalized, the
+corresponding attribute of each task is finalized, unless it has
+been finalized earlier.
+
+!corrigendum C.7.2(15.1/1):
+
+@drepl
+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.
+@dby
+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. Access to
+a task attribute is erroneous if executed concurrently with
+or after the finalization of the task attribute.
!corrigendum C.7.2(17)
-@ddel
+@drepl
When a task terminates, an implementation shall finalize all attributes of
the task, and reclaim any other storage associated with the attributes.
+@dby
+After task attributes are finalized, the implementation shall reclaim any
+other storage associated with the attributes.
-!corrigendum C.7.2(28)
+!corrigendum C.7.2(30)
-@dinsa
-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.
+@dinsb
+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.
@dinst
-If a task terminates before the master of the instantiation of
-Task_Attributes is finalized, an implementation may finalize the object
-corresponding to the attribute of the task at this time (instead of when
-the master of the instantiation is finalized), and reclaim any other
-storage associated with the attribute.
+Finalization of task attributes and reclamation of associated storage
+should be performed as soon as possible after task termination.
!ACATS test
@@ -2153,6 +2187,56 @@
rant about the "interfaces" AI, I would like to point out that this Task
Attribute AI, like most other AI's, will have near-zero effect on
whether people choose Ada!
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, September 18, 2003 7:00 AM
+
+Here is the revised AI-237 (task attribute finalization). It is a 90%
+rewrite. [Editor's note: This is version /06].
+
+I wrote it in accordance with the minutes of the last meeting. In the
+process, I also dealt with anomalies caused by early completion of the
+master of the attributes. You may want to read the wording section, as
+we had not resolved these issues previously.
+
+Frankly, in looking at the slew of problems caused, I would have been
+inclined to impose the restriction that the package can only be
+instantiated at library level. But, as this was not the agreed-upon
+position, I wrote it as we agred.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September 18, 2003 4:19 PM
+
+> Here is the revised AI-237 (task attribute finalization). It is a 90%
+> rewrite.
+
+Well, the editor says its more like a 70% rewrite. :-) You only changed 50% of
+the wording.
+
+> I wrote it in accordance with the minutes of the last meeting. In the
+> process, I also dealt with anomalies caused by early completion of the
+> master of the attributes. You may want to read the wording section, as
+> we had not resolved these issues previously.
+
+You mean in terms of your rewrite. Certainly, the previous version of the AI
+did address those issues.
+
+> Frankly, in looking at the slew of problems caused, I would have been
+> inclined to impose the restriction that the package can only be
+> instantiated at library level. But, as this was not the agreed-upon
+> position, I wrote it as we agred.
+
+I think that would be a bad idea. This case is rather unlikely (a non-library
+level instantiation using a controlled type). Most task attributes are
+elementary types (at least one implementation ONLY allows elementary types for
+task attributes). None of these problems occur in practice when the type does
+not have a significant finalization. (That's why your solution of declaring it
+erroneous doesn't bother me much, either.) I don't think we want to start
+declaring existing code illegal to fix some unlikely problem.
*************************************************************
Questions? Ask the ACAA Technical Agent