CVS difference for ai05s/ai05-0045-1.txt

--- ai05s/ai05-0045-1.txt	2007/04/05 00:33:48	1.1
+++ ai05s/ai05-0045-1.txt	2007/04/06 03:10:41	1.2
@@ -41,32 +41,37 @@
 Add a new note after 9.2(9):
 
 It is possible for newly created tasks to never be activated if the point that
-would initiation the activations is never reached (for example, due to the raising
+would initiate the activations is never reached (for example, due to the raising
 of an exception). In this case, the tasks are never activated.
 
 AARM Note: This also can happen because of an abort, or because of a transfer of
 control out of an extended_return_statement.
 
-Add a new paragraph after 9.3(5):
+Modify paragraph 9.3(5):
 
-If any of the dependent tasks of a master that is waiting for the termination of
-dependent tasks have not been activated, the unactivated tasks become terminated and
-are never activated.
+A task is said to be completed when the execution of its corresponding task_body
+is completed. A task is said to be terminated when any finalization of the
+task_body has been performed (see 7.6.1). The first step of finalizing a master
+(including a task_body) is to wait for the termination of any tasks dependent on
+the master. {At the start of this step, any tasks dependent on that master that
+have not been activated become terminated and are never activated.} The task
+executing the master is blocked until all the dependents have terminated. Any
+remaining finalization is then performed and the master is left.
 
 !discussion
 
 What is important here is what happens if we need to wait for tasks that aren't
-activated. We don't really care why the tasks aren't activated. Thus, the original
+activated. We don't really care why the tasks were never activated. Thus, the original
 wording of 9.2(6) says too much. It also has a race condition, in that if the 
 task is aborted when it reaches the activation point but before the tasks actually
 are activated, this rule doesn't seem to apply.
 
-The wording also is not clear precisely when the tasks become terminated. The tasks
+The wording also is not clear about precisely when the tasks become terminated. The tasks
 being terminated on creation would meet the requirements of this rule. Thus, the value
 of T'Terminated is not well-defined for such tasks. That seems bad.
 
 Because of all of these reasons, we've chosen a much simpler rule that has the same effect.
-Becasue the new rule is specifically about task termination and depends on the definitions
+Because the new rule is specifically about task termination and depends on the definitions
 in that section, it is best put into 9.3. and we've removed the old rule from 9.2 and
 replaced it with a user note.