CVS difference for ais/ai-00165.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00165.txt

--- ais/ai-00165.txt	1998/10/01 03:20:19	1.3
+++ ais/ai-00165.txt	1999/07/29 00:51:02	1.4
@@ -1,5 +1,6 @@
-!standard C.7.2    (16)                               98-06-12  AI95-00165/04
+!standard C.7.2    (16)                               99-07-28  AI95-00165/05
 !class binding interpretation 96-10-04
+!status Corrigendum 2000 99-07-28
 !status WG9 approved 98-06-12
 !status ARG Approved 10-0-0  98-04-01
 !status work item 96-10-04
@@ -8,24 +9,23 @@
 !difficulty Medium
 !subject Recursive use of task attributes isn't considered
 
-!summary 98-03-20
+!summary
 
 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 via instantiated
 interfaces of this generic package, then a call of Set_Value of the
 instantiated package constitutes a bounded error. The call may perform
-as expected or it may result in a deadlock of the calling task and 
-subsequently of the entire partition or of other tasks accessing task 
+as expected or it may result in a deadlock of the calling task and
+subsequently of the entire partition or of other tasks accessing task
 attributes.
 
 Accesses via an Attribute_Handle (as obtained by calling the function
 Reference) are not subject to the atomicity requirement of C.7.2(16).
 Such accesses, if concurrent with each other or with the execution of
 any of the subprograms provided by the package, are erroneous.
- 
 
-!question 98-03-20
+!question
 
 Paragraph 16 of C.7.2 says, in full, "The implementation shall perform
 each of the above operations for a given attribute of a given task
@@ -82,12 +82,11 @@
     end A_Prog;
 
 Finally, what happens if one of the operations of the package is concurrently
-executed with an access via an attribute handle?  Is there an atomicity 
+executed with an access via an attribute handle?  Is there an atomicity
 requirement on the latter as well?
 
+!recommendation
 
-!recommendation 98-03-20
-
 A deadlock cannot be sensibly avoided when a recursive access via one
 of the interfaces of the package occurs to the same task attribute of
 the same task.  Accesses via an Attribute_Handle are not subjected to
@@ -104,23 +103,21 @@
 the initiating call of Set_Value will either deadlock or perform its
 nested accesses as expected. Concurrent accesses via Attribute_Handles
 are deemed erroneous.
-
-The summary of the AI specifies these semantics in more detail. 
 
+The summary of the AI specifies these semantics in more detail.
 
-!wording 98-03-20
+!wording
 
 The wording of the dynamic semantics in C.7.2 should be expanded to
 advise the user of the bounded error situation, respectively the
 erroneousness of concurrent accesses via an Attribute_Handle, as described
-in the summary of this AI. 
+in the summary of this AI.
 
 There should be an additional implementation permission to choose a coarser
 granularity of the lock than needed to keep the operations atomic for each
-individual task attribute of each individual task. 
+individual task attribute of each individual task.
 
-
-!discussion 96-10-04
+!discussion
 
 The atomicity of the operations will require some locking mechanism to
 prevent concurrent accesses to the same task attribute of a given
@@ -131,20 +128,20 @@
 
 If the attribute does not involve controlled types with user-defined
 Adjust and Finalization routines, then a single run-time lock suffices
-to achieve the semantics of RM C.7.2(16). 
+to achieve the semantics of RM C.7.2(16).
 
 If the attribute is of a controlled type or has components of a controlled
 type, then the implicitly invoked user-defined Adjust or Finalize routines
 are presently not forbidden to call on operations of this package for other
 task attributes or even, rather pathologically, for the same task attribute
 of the given task. Whatever locking strategy is applied, the latter will lead
-to a deadlock. The former can lead to a deadlock if the granularity of the 
+to a deadlock. The former can lead to a deadlock if the granularity of the
 lock is any larger than on single attributes of any task, e.g., a lock per
 task or a global run-time lock.
 
 It seems unwise to require all implementations to provide a potentially
 expensive very fine-grained locking on attributes merely to guard against
-the fairly rare situation, in which 
+the fairly rare situation, in which
    - a controlled type is chosen for a task attribute, and
    - the Adjust or Finalize operation of the controlled type
      calls on operations of this package in turn to read or modify
@@ -155,8 +152,55 @@
 The use of attribute handles is not protected by any atomicity
 requirement in the RM, so that their concurrent use must be deemed
 erroneous.
+
+!corrigendum C.7.2(13)
+
+@dinsa
+For all the operations declared in this package, Tasking_Error is raised
+if the task identified by T is terminated. Program_Error is raised if the
+value of T is Null_Task_ID.
+@dinst
+@i<@s8<Bounded (Run-Time) Errors>>@hr
+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 it
+may result in forever blocking the calling task and subsequently some
+or all tasks of the partition.
+
+!corrigendum C.7.2(15)
+
+@dinsa
+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.
+@dinst
+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 above operations.
+
+!corrigendum C.7.2(16)
+
+@drepl
+The implementation shall perform each of the above operations for a
+given attribute of a given task atomically with respect to any other of the
+above operations for the same attribute of the same task.
+@dby
+The implementation shall perform each of the above operations for a
+given attribute of a given task atomically with respect to any other 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.
+
+!ACATS test
+
+This ruling is not testable. It says that some operations are erroneous;
+erroneous programs are never testable (as they can do anything). It defines
+other cases as bounded errors. The bounded error case allows deadlock, which
+makes it untestable as well.
 
-!appendix 96-11-16
+!appendix
 
 !section C.7.2(16)
 !subject Recursive use of task attributes isn't considered
@@ -467,27 +511,27 @@
 are presently not forbidden to call on operations of this package for other
 task attributes or even, rather pathologically, for the same task attribute
 of the given task. Whatever locking strategy is applied, the latter will lead
-to a deadlock. The former can lead to a deadlock if the granularity of the 
+to a deadlock. The former can lead to a deadlock if the granularity of the
 lock is any larger than on single attributes of any task, e.g., a lock per
 task or a global run-time lock."
 
-There are no deadlocks when a single global lock is used in the former case above.  Perhaps 
-what was intended was "... or a lock per attribute."  Also, deadlocks are possible even 
-with maximally fine-grained locking, which makes the premise of the following paragraph 
+There are no deadlocks when a single global lock is used in the former case above.  Perhaps
+what was intended was "... or a lock per attribute."  Also, deadlocks are possible even
+with maximally fine-grained locking, which makes the premise of the following paragraph
 somewhat unclear:
 
 "It seems unwise to require all implementations to provide a potentially
 expensive very fine-grained locking on attributes merely to guard against
 the fairly rare situation..."
 
-This seems to suggest that fine-grained locking guards against deadlocks, but this is only 
-partly true: what makes deadlocks possible is allowing a lock granularity less than that of 
-a single global lock.  The implementation permission being considered is to allow some 
-deadlocks *in addition* to the ones that are present for cell-level locking, so as to 
+This seems to suggest that fine-grained locking guards against deadlocks, but this is only
+partly true: what makes deadlocks possible is allowing a lock granularity less than that of
+a single global lock.  The implementation permission being considered is to allow some
+deadlocks *in addition* to the ones that are present for cell-level locking, so as to
 permit implementations to lock by groups.
 
-This counterintuitive aspect of the situation comes from there being a special case: with a 
-single global lock, there cannot be a deadlock, barring circular use; in all other 
+This counterintuitive aspect of the situation comes from there being a special case: with a
+single global lock, there cannot be a deadlock, barring circular use; in all other
 situations, the finer the lock granularity the fewer the potential deadlocks.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent