CVS difference for ais/ai-00266.txt

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

--- ais/ai-00266.txt	2002/03/12 01:14:42	1.4
+++ ais/ai-00266.txt	2002/03/12 01:21:15	1.5
@@ -1,4 +1,4 @@
-!standard D.2.2 (5)                                02-03-07  AI95-00266/04
+!standard D.2.2 (5)                                02-03-09  AI95-00266/05
 !standard D.7 (00)
 !class amendment 01-05-10
 !status work item 01-05-10
@@ -9,16 +9,15 @@
 
 !summary
 
-A mechanism is proposed for associating a task group object with a task.
-The task group object receives notification when the task is about to
-terminate. If a task terminates due to an unhandled exception,
-the exception occurrence is passed to the group. By default,
-when a new task is created, the task group of its master becomes
-its task group. However, a master may locally specify a different
-"creation" group for its subtasks.
+A mechanism is proposed for associating a task group object with a task. The
+task group object receives notification when the task is about to terminate. If
+a task terminates due to an unhandled exception, the exception occurrence is
+passed to the group. By default, when a new task is created, the task group of
+its master becomes its task group. However, a master may locally specify a
+different "creation" group for its subtasks.
 
-A default task group may be specified to handle termination for tasks with
-no task group of their own.
+A default task group may be specified to handle creation and termination
+for tasks with no task group of their own.
 
 !problem
 
@@ -36,20 +35,25 @@
 
             type Root_Task_Group is abstract tagged limited private;
 
-            procedure Unhandled_Exception(TG : access Root_Task_Group;
+	    procedure Task_Created(TG : in out Root_Task_Group;
+			ID : Task_Identification.Task_ID);
+	      -- Called when a task is created.
+	      -- This operation by default does nothing.
+
+            procedure Unhandled_Exception(TG : in out Root_Task_Group;
                         ID : Task_Identification.Task_ID;
                         Excep : Exceptions.Exception_Occurrence) is abstract;
               -- Called immediately prior to task termination,
               -- if the task completed due to an unhandled exception.
               -- This operation must be overridden.
 
-            procedure Aborted(TG : access Root_Task_Group;
+            procedure Aborted(TG : in out Root_Task_Group;
                         ID : Task_Identification.Task_ID); -- is null;
               -- Called immediately prior to task termination,
               -- if the task completed due to abortion.
               -- By default, this operation does nothing.
 
-            procedure Normal_Termination(TG : access Root_Task_Group;
+            procedure Normal_Termination(TG : in out Root_Task_Group;
                         ID : Task_Identification.Task_ID); -- is null;
               -- Called immediately prior to task termination,
               -- if the task completed due to completing the last statement
@@ -57,7 +61,7 @@
               -- alternative.
               -- By default, this operation does nothing.
 
-            procedure Never_Activated(TG : access Root_Task_Group;
+            procedure Never_Activated(TG : in out Root_Task_Group;
                         ID : Task_Identification.Task_ID); -- is null;
               -- Called when a task is aborted before it
               -- is activated, by the would-be activator
@@ -73,7 +77,7 @@
             function Current_Task_Group return Task_Group_Access;
                   -- Return the task group of the current task.
                   -- This returns null if the current task has no
-		  -- associated task group.  When a task with no task
+		  -- associated task group. When a task with no task
                   -- group terminates, the current default task
 		  -- group (see below) will be notified of termination.
 		  -- Note that the access value returned may designate
@@ -124,29 +128,35 @@
             -- Not specified by the language
         end Ada.Task_Groups;
 
-When a task is created, its task group is determined by the
-"task creation group" associated with either its creator, if created by a
-declaration, or with its access type, if created by an allocator.
-The environment task has no associated task group, though it
-may establish a task creation group for its subtasks.
+When a task is created, its task group is determined by the "task creation
+group" associated with either its creator, if created by a declaration, or with
+its access type, if created by an allocator. The environment task has no
+associated task group, though it may establish a task creation group for its
+subtasks.
+
+The task creation group for a task starts out as the same as the task's own
+group, if any. As the task proceeds, a local task creation group may be
+established, by declaring a limited controlled object of the type
+"Local_Task_Creation_Group." When the Local_Task_Creation_Group is finalized,
+the task creation group is restored to its value at the time the local group
+was established. The task creation group for an access type is determined by
+the task creation group in effect when the access type declaration is
+elaborated.
+
+Immediately after a task is created, its task group, if any, is notified by
+calling the Task_Created primitive of the task group. If the task does not have
+a task group of its own, the default task group, if any, is notified. When the
+Task_Created operation is called, a call on Current_Task will identify the
+creator of the task, rather than the newly created task itself (since the new
+task is generally not activated until later).
 
 Immediately prior to task termination, the task group, if any, of the
-terminating task is notified.  If the task has no task group, then
-the default task group at the time of termination, if any, is notified.
-
-The task creation group for a task starts out as the same as
-the task's own group, if any. As the task proceeds, a local
-task creation group may be established, by declaring a limited
-controlled object of the type "Local_Task_Creation_Group." When
-the Local_Task_Creation_Group is finalized, the task creation group
-is restored to its value at the time the local group was established.
-The task creation group for an access type is determined by
-the task creation group in effect when the access type declaration
-is elaborated.
+terminating task is notified. If the task has no task group, then the default
+task group at the time of termination, if any, is notified.
 
 Notifying a task group of (impending) termination consists of calling the
 appropriate primitive operation of the task group, as determined by how the
-task terminates.  If the task completes due to an abort statement, the Aborted
+task terminates. If the task completes due to an abort statement, the Aborted
 operation is called. If the task completes due to an unhandled exception, the
 Unhandled_Exception operation is called. If the task completes due to
 completing the last statement of the task body, or as part of waiting on a
@@ -158,14 +168,14 @@
 If a task never begins execution (because it is aborted prior to activation),
 then the Never_Activated operation of its task group is called by its activator
 at the point where it would have been activated (i.e. immediately
-after the "begin").  It is unspecified whether some or all of its (unaborted)
+after the "begin"). It is unspecified whether some or all of its (unaborted)
 "sibling" tasks are activated prior to Never_Activated being called.
 
 The result of calling Current_Task while executing Never_Activated will
 identify the activator. While executing the Normal_Termination and
-Unhandled_Exception operations, the result of calling Current_Task
-identifies the task about to terminate. It is not specified what is
-returned by Current_Task within the Aborted operation.
+Unhandled_Exception operations, the result of calling Current_Task identifies
+the task about to terminate. It is not specified what is returned by
+Current_Task within the Aborted operation.
 
 When Unhandled_Exception, Aborted, or Normal_Termination are called,
 the Terminated attribute of the terminating task will be False.
@@ -181,14 +191,19 @@
 concurrent termination of tasks. Hence, these operations should be implemented
 in a reentrant manner.
 
-Note that Local_Task_Creation_Group may also be used in a library-level
-package to set the task creation group for library-level tasks.  The task
-creation group setting will persist until it is overridden by some subsequent
-elaboration of a Local_Task_Creation_Group object.  Hence, if this
-approach is used to manage library level tasks, such a
-Local_Task_Creation_Group object should appear at the beginning of
-every package spec or body that declares tasks or access types
-that designate tasks.
+Note that Local_Task_Creation_Group may also be used in a library-level package
+to set the task creation group for library-level tasks. The task creation
+group setting will persist until it is overridden by some subsequent
+elaboration of a Local_Task_Creation_Group object. Hence, if this approach is
+used to manage library level tasks, such a Local_Task_Creation_Group object
+should appear at the beginning of every package spec or body that declares
+tasks or access types that designate tasks.
+
+No_Task_Groups Restriction Identifier
+
+The Restriction identifier "No_Task_Groups" is defined. When this restriction
+is in force for a partition, it is illegal to mention the Task_Groups package
+in a with clause of any compilation unit of the partition.
 
 !wording
 
@@ -197,65 +212,67 @@
 
 Many safety critical and high integrity systems prohibit exception handling,
 and so the use of a "when others" handler at the task body level is then not
-available. Furthermore, there may be many tasks in a system, and
-a systematic, centralized way of handling unhandled exceptions is
-preferred to having to repeat code in every task body.
-
-We have proposed a technique that is reminiscent of what Java does, in
-that it establishes a separate abstraction, called a task group ("thread
-group" in Java) which receives notification of task termination.
-By default, a task inherits the task group its master task.  However,
-the master may establish a "task creation group" to change what
-task group is used for its subtasks.
-
-This proposal allows each scope to set up its own local task creation
-group, but by default allows tasks to inherit the task group from its master
-task upon creation. This gives a combination of fine control when needed,
-along with the convenience of inheritance otherwise.
-
-We ensure that a task cannot outlive its task group because
-local task creation groups are specified using a declaration
-of a local controlled object, rather than by an explicit subprogram
-call. For a task created by an allocator, we use the task creation
-group the master had at the time the access type was elaborated,
-again, to ensure that the task cannot outlive its task group
+available. Furthermore, there may be many tasks in a system, and a systematic,
+centralized way of handling unhandled exceptions is preferred to having to
+repeat code in every task body.
+
+We have proposed a technique that is reminiscent of what Java does, in that it
+establishes a separate abstraction, called a task group ("thread group" in
+Java) which receives notification of task termination. By default, a task
+inherits the task group its master task. However, the master may establish a
+"task creation group" to change what task group is used for its subtasks.
+
+This proposal allows each scope to set up its own local task creation group,
+but by default allows tasks to inherit the task group from its master task upon
+creation. This gives a combination of fine control when needed, along with the
+convenience of inheritance otherwise.
+
+We ensure that a task cannot outlive its task group because local task creation
+groups are specified using a declaration of a local controlled object, rather
+than by an explicit subprogram call. For a task created by an allocator, we use
+the task creation group the master had at the time the access type was
+elaborated, again, to ensure that the task cannot outlive its task group
 (barring early unchecked deallocation).
 
-We provide a default task group to allow most or all of the tasks
-in a program to notify a single task group, if appropriate.
+We provide a default task group to allow most or all of the tasks in a program
+to notify a single task group, if appropriate.
 
-We originally did not have the notion of a task creation group,
-while instead allowing a task to change its own group while
-it executed to indirectly affect the group used for subtasks.
-This ended up having more complicated semantics, and introduced
-additional possibilities for dangling references to task groups.
-
-We originally had a Task_ID parameter in Current_Task_Group as
-a way to query the task group of any task. However, this
-introduced too many possibilities for dangling references,
-as a task might terminate immediately after the call and its
-task group might go out of scope. An attribute of a task object
-might be an alternative safer way of providing this functionality.
-By using an attribute, we could avoid the need for using an access
-value, and could instead make the attribute reference denote the
-task group itself, as a variable, analogous to the way the
-Storage_Pool attribute works. On the other hand, if you can
-name the task, then you can figure out its task group by simply
-calling Current_Task_Creation_Group immediately prior to its
-declaration, and saving the value in a local variable.
-
-We considered a mechanism using pragmas or attributes to specify the
-task creation group associated with a scope, but the mechanism became too
-heavy. The Local_Task_Creation_Group controlled type provides much of the
-same capability without having to define pragmas or attributes.
-On the other hand, the semantics have been simplified a bit since the
-original proposal, and a pragma equivalent to the Local_Task_Creation_Group
-declaration might be easier to define now. It would also have the
-side benefit that it could deal with library-level tasks somewhat
-more cleanly, as the pragma's effect could be limited to the tasks
-of a single library package, without "spilling over" to library packages
-that are elaborated immediately after the package.  But this would
-not be a pragma that could safely be ignored, as it has a significant
+We provide an operation for notifying a task group when a task is created, so
+that it may keep track of all subtasks that exist, between their creation and
+their termination.
+
+All of the primitive operations of the abstract Root_Task_Group type have
+defaults except for Unhandled_Exception. Only that operation must be
+overridden; the others do nothing if not overridden.
+
+We originally did not have the notion of a task creation group, while instead
+allowing a task to change its own group while it executed to indirectly affect
+the group used for subtasks. This ended up having more complicated semantics,
+and introduced additional possibilities for dangling references to task groups.
+
+We originally had a Task_ID parameter in Current_Task_Group as a way to query
+the task group of any task. However, this introduced too many possibilities for
+dangling references, as a task might terminate immediately after the call and
+its task group might go out of scope. An attribute of a task object might be an
+alternative safer way of providing this functionality. By using an attribute,
+we could avoid the need for using an access value, and could instead make the
+attribute reference denote the task group itself, as a variable, analogous to
+the way the Storage_Pool attribute works. On the other hand, if you can name
+the task, then you can figure out its task group by simply calling
+Current_Task_Creation_Group immediately prior to its declaration, and saving
+the value in a local variable.
+
+We considered a mechanism using pragmas or attributes to specify the task
+creation group associated with a scope, but the mechanism became too heavy. The
+Local_Task_Creation_Group controlled type provides much of the same capability
+without having to define pragmas or attributes. On the other hand, the
+semantics have been simplified a bit since the original proposal, and a pragma
+equivalent to the Local_Task_Creation_Group declaration might be easier to
+define now. It would also have the side benefit that it could deal with
+library-level tasks somewhat more cleanly, as the pragma's effect could be
+limited to the tasks of a single library package, without "spilling over" to
+library packages that are elaborated immediately after the package. But this
+would not be a pragma that could safely be ignored, as it has a significant
 semantic effect over subsequent calls on functions like
 Current_Task_Creation_Group.
 

Questions? Ask the ACAA Technical Agent