CVS difference for ai05s/ai05-0045-1.txt
--- ai05s/ai05-0045-1.txt 2007/12/13 04:39:36 1.5
+++ ai05s/ai05-0045-1.txt 2008/05/10 05:14:33 1.6
@@ -1,4 +1,4 @@
-!standard 9.2(6) 07-11-28 AI05-0045-1/04
+!standard 9.2(6) 08-04-21 AI05-0045-1/05
!class binding interpretation 07-04-04
!status ARG Approved 9-0-0 06-11-10
!status work item 07-04-04
@@ -9,7 +9,8 @@
!subject Termination of unactivated tasks
!summary
-Tasks that are created but never activated become terminated when their master is finalized.
+Tasks that are created but never activated become terminated when their master
+is finalized.
!question
@@ -21,12 +22,12 @@
A return statement for a type containing tasks that is left without being
completed is going to leave the master of those tasks. But the activation point
-(at the site of the function call) could very well still be executed, for instance
-if there is a local handler. Moreover, an extended_return can be left by an exit or
-goto statement (not one of these cases listed in this sentence), and such exits
-will occur mainly in cases where the activation point will in fact be reached. How
-can the master being left wait for tasks that have not yet been activated, but are
-not terminated because this paragraph does not apply?
+(at the site of the function call) could very well still be executed, for
+instance if there is a local handler. Moreover, an extended_return can be left
+by an exit or goto statement (not one of these cases listed in this sentence),
+and such exits will occur mainly in cases where the activation point will in
+fact be reached. How can the master being left wait for tasks that have not yet
+been activated, but are not terminated because this paragraph does not apply?
!recommendation
@@ -37,16 +38,16 @@
Replace 9.2(6) by:
If the master that directly encloses the point where the activation of a task T
-would be initiated, completes before the activation of T is initiated, T becomes
-terminated and is never activated. Furthermore, if a return statement is left
-such that the return object is not returned to the caller, any task that was
-created as a part of the return object or one of its coextensions immediately
-becomes terminated and is never activated.
-
- AARM Notes: The first case can only happen if the activation point of T is not
- reached due to an exception being raised or a task or statement being aborted.
- Note that this is exclusive; if the master is being finalized, we're already
- past the activation point.
+would be initiated, completes before the activation of T is initiated, T
+becomes terminated and is never activated. Furthermore, if a return statement
+is left such that the return object is not returned to the caller, any task
+that was created as a part of the return object or one of its coextensions
+immediately becomes terminated and is never activated.
+
+ AARM Notes: The first case can only happen if the activation point of T is
+ not reached due to an exception being raised or a task or statement being
+ aborted. Note that this is exclusive; if the master is being finalized,
+ we're already past the activation point.
The second case can happen with an exception being raised in a return
statement, by an exit or goto from an extended_return_statement, or by a
@@ -56,51 +57,53 @@
!discussion
-What is important here is what happens if the master that directly encloses
-the activation point of any unactivated tasks is completed. We don't care why the
-tasks were never activated or where they were created. 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 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 rewritten the rule in terms of completion of
-a master rather than "reaching the point of activation".
-
-While the most critical point is when the master of the tasks begins to finalize (because
-we would need to wait for the unactivated tasks at that point), writing the rule
-that way could cause unactivated tasks to hang around in a limbo state for a long time.
-(Consider an allocator for an access-to-task that is declared at library level; the
-master is that of the environment task.) Thus we talk about the master of that encloses
-the activation point of the task.
-
-We need a special rule for a return statement which is completed without returning to the
-caller (a "failed" return), because the activation point of those tasks may be executed
-if the function executes a second return statement successfully. In that case, the tasks
-created by the failed return should never be activated, while the second set created by
-the later successful return do need to be activated. This doesn't fit cleanly into
-the model.
+What is important here is what happens if the master that directly encloses the
+activation point of any unactivated tasks is completed. We don't care why the
+tasks were never activated or where they were created. 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 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 rewritten the rule in terms of
+completion of a master rather than "reaching the point of activation".
+
+While the most critical point is when the master of the tasks begins to
+finalize (because we would need to wait for the unactivated tasks at that
+point), writing the rule that way could cause unactivated tasks to hang around
+in a limbo state for a long time. (Consider an allocator for an access-to-task
+that is declared at library level; the master is that of the environment task.)
+Thus we talk about the master that encloses the activation point of the task.
+
+We need a special rule for a return statement which is completed without
+returning to the caller (a "failed" return), because the activation point of
+those tasks may be executed if the function executes a second return statement
+successfully. In that case, the tasks created by the failed return should never
+be activated, while the second set created by the later successful return do
+need to be activated. This doesn't fit cleanly into the model.
!corrigendum 9.2(6/2)
@drepl
Should the task that created the new tasks never reach the point where it would
initiate the activations (due to an abort or the raising of an exception), the
-newly created tasks become terminated and are never activated.
+newly created tasks become terminated and are never activated.
@dby
-If the master that directly encloses the point where the activation of a task @i<T>
-would be initiated, completes before the activation of @i<T> is initiated, @i<T> becomes
-terminated and is never activated. Furthermore, if a return statement is left
-such that the return object is not returned to the caller, any task that was
-created as a part of the return object or one of its coextensions immediately
-becomes terminated and is never activated.
+If the master that directly encloses the point where the activation of a task
+@i<T> would be initiated, completes before the activation of @i<T> is
+initiated, @i<T> becomes terminated and is never activated. Furthermore, if a
+return statement is left such that the return object is not returned to the
+caller, any task that was created as a part of the return object or one of its
+coextensions immediately becomes terminated and is never activated.
!ACATS test
-An ACATS C-Test should be created to check the extended_return case with a transfer of control:
+An ACATS C-Test should be created to check the extended_return case with a
+transfer of control:
return A : Type_with_a_Task do
...
@@ -164,11 +167,11 @@
The wording of 9.2(6) is terrible, but we've lived with it for years.
-Taken literally, the wording is ridiculous: "at the point where something
+Taken literally, the wording is ridiculous: "at the point where something
will never happen, do something", or something like that.
-If, strictly speaking, this is defined at all (a point I am not willing to
-concede), it certainly requires a crystal ball - do or do not do something now
+If, strictly speaking, this is defined at all (a point I am not willing to
+concede), it certainly requires a crystal ball - do or do not do something now
depending on what is going to happen in the future. This reminds me of the old
definition of the Max_Size_In_Storage_Units attribute ("the maximum value ...
that will be requested ...").
@@ -180,7 +183,7 @@
In your example, the set of tasks associated with a different extended return
statement (or even a different elaboration of the same extended return statement)
-is a different set. Thus, the task activation point for the original set of
+is a different set. Thus, the task activation point for the original set of
tasks is no longer reachable after the goto statement and 9.2(6) does apply.
****************************************************************
@@ -188,8 +191,8 @@
From: Randy Brukardt
Date: Monday, April 2, 2007 4:57 PM
-> If, strictly speaking, this is defined at all (a point I am not willing to
-> concede), it certainly requires a crystal ball - do or do not do something now
+> If, strictly speaking, this is defined at all (a point I am not willing to
+> concede), it certainly requires a crystal ball - do or do not do something now
> depending on what is going to happen in the future. This reminds me of the old
> definition of the Max_Size_In_Storage_Units attribute ("the maximum value ...
> that will be requested ...").
@@ -202,7 +205,7 @@
Here, you *are* going to reach the task activation point, but you *still* don't want
to activate the tasks. That is completely different.
-> What this wording really means is "at the point where the task activation
+> What this wording really means is "at the point where the task activation
> point becomes unreachable, terminate the new tasks".
Maybe. I'm not sure; I always thought it meant "if you reach the task waiting point
@@ -232,7 +235,7 @@
of the tasks is finalized. Keep in mind that there isn't any wording like 3.10.2(10.1/2)
that applies to the activation point: it never changes its location! So it is initially
outside of the master of the object; then when the return happens, the master changes so
-that the activation point is inside as usual.
+that the activation point is inside as usual.
In an example like this, it's clear that the tasks are gone before the activation point
is reached, but it surely will be reached.
@@ -309,7 +312,7 @@
> tasks while still still in the callee. The caller is unaware that these
> tasks were ever created and is certainly not responsible for terminating
> them. In this example,
->
+>
> function F return R is
> begin
> return R'(Some_Task_Component => <>,
@@ -320,11 +323,11 @@
> Do_A_Bunch_Of_Stuff;
> return ... ;
> end F;
->
+>
> , any tasks that were created as part of the aggregate evaluation before
> Constraint_Error was raised would be terminated before, not after,
> the call to Do_A_Bunch_Of_Stuff.
->
+>
> According to the wording you suggest, they would be terminated after.
No, that's wrong. The master of a return statement is the statement itself
@@ -350,7 +353,7 @@
> could tell the difference.
There is no difference, so I don't think you can tell it. ;-)
-
+
> I can't think of any way that anyone could tell the difference, but that
> is a much weaker statement.
@@ -360,7 +363,7 @@
> propose. Perhaps it could be augmented with an explicit implementation
> permission to terminate the tasks earlier; or, at the very least, an
> AARM note indicating that this was the intent.
->
+>
> What do you think?
I don't think you need to terminate the tasks earlier (or can, for that matter), because
@@ -374,7 +377,7 @@
So I think you've convinced me that I'm on the right track. It certainly is simpler than
talking about executing the point of task activation. I'll write it up this way and then
-the full ARG can tear it to bits...
+the full ARG can tear it to bits...
****************************************************************
@@ -550,42 +553,42 @@
> caller as part or coextension of a return object, task T2
> is never activated and becomes terminated.
-Hmm. I think the source of the confusion here is mentioning task T1.
-We all know that the conditions being discussed can only happen if
-there something above the master which becomes terminated. But that has
-nothing to do with the conditions addressed. We have an
+Hmm. I think the source of the confusion here is mentioning task T1.
+We all know that the conditions being discussed can only happen if
+there something above the master which becomes terminated. But that has
+nothing to do with the conditions addressed. We have an
uninterruptable last wishes situation:
-If a master that includes (directly or indirectly) the creation of a
-task begins finalization prior to either initiating the activation of
-the task or returning the task to a caller as part or coextension of a
+If a master that includes (directly or indirectly) the creation of a
+task begins finalization prior to either initiating the activation of
+the task or returning the task to a caller as part or coextension of a
return object, the task is never activated and becomes terminated.
-So leaving the scope of the master has to change the status of the
-created task to terminated. But editing it down like this makes it
-clear that it is either redundant or wrong! Currently 9.1(4) says: "For
-tasks created by the evaluation of an allocator, the activations are
-initiated as the last step of evaluating the allocator, after completing
-any initialization for the object created by the allocator, and prior to
-returning the new access value." This separation into two steps means
-that the case where you have an allocator that creates more than one
-task can result in one task becoming activated and immediately aborting
-the parent before it can finish activating all the tasks. Worse, what
-happens when a created task creates another task as part of its
+So leaving the scope of the master has to change the status of the
+created task to terminated. But editing it down like this makes it
+clear that it is either redundant or wrong! Currently 9.1(4) says: "For
+tasks created by the evaluation of an allocator, the activations are
+initiated as the last step of evaluating the allocator, after completing
+any initialization for the object created by the allocator, and prior to
+returning the new access value." This separation into two steps means
+that the case where you have an allocator that creates more than one
+task can result in one task becoming activated and immediately aborting
+the parent before it can finish activating all the tasks. Worse, what
+happens when a created task creates another task as part of its
activation? I could, but, won't, write a test.
If we say instead:
-If a master that includes (directly or indirectly) the creation of a
-task begins finalization prior to either initiating the activation of
-the task or returning the task to a caller as part or coextension of a
+If a master that includes (directly or indirectly) the creation of a
+task begins finalization prior to either initiating the activation of
+the task or returning the task to a caller as part or coextension of a
return object, the task becomes terminated.
-There are no orphans around, and the order of creation of tasks in an
-allocator is immaterial. Does this allow, in the nested tasks case, for
-a situation where the new task has observable effects during elaboration
-of the task body, then fails, taking out the parent? Sure. But I don't
-think the intent is to change that. As I see it, all that we really
+There are no orphans around, and the order of creation of tasks in an
+allocator is immaterial. Does this allow, in the nested tasks case, for
+a situation where the new task has observable effects during elaboration
+of the task body, then fails, taking out the parent? Sure. But I don't
+think the intent is to change that. As I see it, all that we really
need to do is insure that tasks don't outlive their master.
****************************************************************
@@ -677,16 +680,16 @@
>claims that it does not, but has no language wording to prove that; I claim
>it is unclear and thus we need to fix it.
-Ah, I was assuming that you wanted to include created tasks that have
-not yet been activated. As I read the intent, tasks that are not yet
-activated are affected, and running tasks are only affected if their
-master is aborted. (They become abnormal, then must terminate before
-the master is completes finalization.) That was the distinction I was
-trying to make. In that case, you have to split the hairs I was
-splitting about when a task gets activated. My point was that in the
-case of record designated by an access value containing more than one
-task with say library unit masters, it matters whether all are activated
-simultaneously, or if some but not all tasks can be activated before the
+Ah, I was assuming that you wanted to include created tasks that have
+not yet been activated. As I read the intent, tasks that are not yet
+activated are affected, and running tasks are only affected if their
+master is aborted. (They become abnormal, then must terminate before
+the master is completes finalization.) That was the distinction I was
+trying to make. In that case, you have to split the hairs I was
+splitting about when a task gets activated. My point was that in the
+case of record designated by an access value containing more than one
+task with say library unit masters, it matters whether all are activated
+simultaneously, or if some but not all tasks can be activated before the
abort.
>>If a master that includes (directly or indirectly) the creation of a
@@ -699,10 +702,10 @@
>it is clear that the finalization of a master of a task other than the one
>that created the task is irrelevant; that is not clear here.
-Right, it is that never "activated and becomes terminated" that concerns
-me. If the master of the tasks is left as part of the termination, no
-problem. But if the master of the created tasks is not finalized along
-with the task creating the new tasks, the question of indivisibility vs.
+Right, it is that never "activated and becomes terminated" that concerns
+me. If the master of the tasks is left as part of the termination, no
+problem. But if the master of the created tasks is not finalized along
+with the task creating the new tasks, the question of indivisibility vs.
some order matters.
>>So leaving the scope of the master has to change the status of the
@@ -719,11 +722,11 @@
>This is well-defined: aborting a task causes any masters it has to be
>finalized. So it is clearly covered by the wording.
-Yes, my wording here probably should have used Tuck's task
-designations. Even then it is not clear. Let me try again. Task T1
-creates two tasks by means of an allocator. Task T1 is the master, or
-includes the master of task T2. Task T3 and possibly more. are also
-created by the allocator, but have other masters. For simplicity assume
+Yes, my wording here probably should have used Tuck's task
+designations. Even then it is not clear. Let me try again. Task T1
+creates two tasks by means of an allocator. Task T1 is the master, or
+includes the master of task T2. Task T3 and possibly more. are also
+created by the allocator, but have other masters. For simplicity assume
library level masters.
>>Worse, what happens when a created task creates another task as part
@@ -733,22 +736,22 @@
>task that created the task; and that will always be finalized. The inner
>task will be terminated before the outer one, and that is as it should be.
-Maybe I should write the example. T1 creates T2 and is directly or
-indirectly its master. Task T2 as part of its activation creates T5 and
-T6 library level masters. T6 raises Tasking_Error as part of, or
-immediately subsequent to its activation. If there are no handlers
-intervening this will terminate T2 then T1. But what about T5? Can T5
-have completed activation before T6? If so since it has a library level
-master, it stays alive and can have observable effects. I've always
-assumed that 9.2 allowed such tasks to survive termination of their
-creator, and that some such tasks and not others might have been
-activated, if one of a set of task activations raises Tasking_Error in
-its creator. See AARM 9.2(5.a). Tasking_Error is only raised once, even
-if several tasks being activated together fail. This is where I get the
-"some order" semantics. You don't have to elaborate the
-declarative_parts of the various task_bodies sequentially, but if you
-don't you have to collect all the Tasking_Errors raised and pass on just
-one. See AARM 9.2(5.b). Yes, these are very much not normative text,
+Maybe I should write the example. T1 creates T2 and is directly or
+indirectly its master. Task T2 as part of its activation creates T5 and
+T6 library level masters. T6 raises Tasking_Error as part of, or
+immediately subsequent to its activation. If there are no handlers
+intervening this will terminate T2 then T1. But what about T5? Can T5
+have completed activation before T6? If so since it has a library level
+master, it stays alive and can have observable effects. I've always
+assumed that 9.2 allowed such tasks to survive termination of their
+creator, and that some such tasks and not others might have been
+activated, if one of a set of task activations raises Tasking_Error in
+its creator. See AARM 9.2(5.a). Tasking_Error is only raised once, even
+if several tasks being activated together fail. This is where I get the
+"some order" semantics. You don't have to elaborate the
+declarative_parts of the various task_bodies sequentially, but if you
+don't you have to collect all the Tasking_Errors raised and pass on just
+one. See AARM 9.2(5.b). Yes, these are very much not normative text,
but I don't think it is wise to change the implied model.
>>If we say instead:
@@ -762,22 +765,22 @@
>task can't be both terminated and pending activation, Essentially, you've
>introduced a race condition.
-No, I'm trying to preserve a race condition! As far as any
-implemetation is concerned, they can choose not to have tasks in such as
-state. A task can become terminated prior to or in the middle of
-activation. In particular, if an implementation decides to allow
-parallel activation, it is possible for two tasks each to see the other
-as pending activation or terminated. The same thing can occur if the
-parent or master is aborted--if a task is being elaborated on one
-processor while another is causing it to become abnormal, the task whose
+No, I'm trying to preserve a race condition! As far as any
+implemetation is concerned, they can choose not to have tasks in such as
+state. A task can become terminated prior to or in the middle of
+activation. In particular, if an implementation decides to allow
+parallel activation, it is possible for two tasks each to see the other
+as pending activation or terminated. The same thing can occur if the
+parent or master is aborted--if a task is being elaborated on one
+processor while another is causing it to become abnormal, the task whose
task body is being elaborated can be in both states simultaneously.
- From an RM perspective, we have a group of tasks being activated
-simultaneously from the point of the task doing the activation, but not
-from other points of view. In particular if a task creates other tasks
-by allocators during activation, they can look at their creator. (Or for
-that matter, their siblings, if an object contains several tasks.) They
-cannot see the creating task as both callable and terminated, but which
+ From an RM perspective, we have a group of tasks being activated
+simultaneously from the point of the task doing the activation, but not
+from other points of view. In particular if a task creates other tasks
+by allocators during activation, they can look at their creator. (Or for
+that matter, their siblings, if an object contains several tasks.) They
+cannot see the creating task as both callable and terminated, but which
they see in certain programs should be implementation dependent.
>>There are no orphans around, and the order of creation of tasks in an
@@ -791,14 +794,14 @@
>that matter), since every created task belongs to a master, and all masters
>are finalized. So there is no way for an orphan to be created. I think
>you're making a problem where none existed.
-
-I think we are using slightly different definitions of orphans, but it
-doesn't matter in that we agree that there are none. I was thinking of
-tasks being activated when their creator, not master, is aborted. Either
-the task becomes activated before its creator is terminated, or it dies
-before the creator is left. In either case, it is safe for the
-implementation to refer to data owned by the creator during activation.
-Whether implemetations do that or copy any necessary data to the new TCB
+
+I think we are using slightly different definitions of orphans, but it
+doesn't matter in that we agree that there are none. I was thinking of
+tasks being activated when their creator, not master, is aborted. Either
+the task becomes activated before its creator is terminated, or it dies
+before the creator is left. In either case, it is safe for the
+implementation to refer to data owned by the creator during activation.
+Whether implemetations do that or copy any necessary data to the new TCB
before activation is an implementation detail.
****************************************************************
@@ -996,46 +999,46 @@
> This wording has been bothering me for several days based on something
> Robert Eachus said, and I've finally figured out what's the issue is.
-I knew we were talking past each other. I think I now know what you
+I knew we were talking past each other. I think I now know what you
were focusing on.
> I can't convince myself that it must be the case that the same master
> encloses the creation and the activation point of a task (even in the
> absence of a return statement). There are so many things that create masters
> now that it is hard to reason about them, and it is trivial to add some to
-> declarations (via expressions or Initialize routines).
+> declarations (via expressions or Initialize routines).
-I'm convinced that all activations are enclosed in the master, or the
-master is at library level. The problem is that you can have nested
-activations, and when that happens, specifying the master in a sentence
-is tough. From an implementation point of view, it is easy. The master
-is deterimined at compile time, by the static nesting of the appropriate
-declaration. Of course, that declaration can be a task declaration, an
+I'm convinced that all activations are enclosed in the master, or the
+master is at library level. The problem is that you can have nested
+activations, and when that happens, specifying the master in a sentence
+is tough. From an implementation point of view, it is easy. The master
+is deterimined at compile time, by the static nesting of the appropriate
+declaration. Of course, that declaration can be a task declaration, an
object declaration, or an access type declaration..
> In any case, I don't think we really need to talk about the creation the
> task; that's not very relevant as it is only the activation point that
> matters. If we don't do that, then we can eliminate two issues with this
-> wording: the "indirectly" business, and any concern about which
+> wording: the "indirectly" business, and any concern about which
> masters are
> involved (or not involved).
>
> The wording could be something like:
>
-> "If a master that directly encloses the point where the activation of
+> "If a master that directly encloses the point where the activation of
> a task
> T would be initiated begins finalization before the activation of T is
> initiated, T becomes terminated and is never activated."
-Good. This is what I was really trying to explain. I hope you mean what
-I was asking for though. Activation is an indivisible operation from
-the point of view of the activating task: A group of tasks all get
+Good. This is what I was really trying to explain. I hope you mean what
+I was asking for though. Activation is an indivisible operation from
+the point of view of the activating task: A group of tasks all get
initiated at a particular point in the execution.
-However, that covers a multitude of execution during the elaboration of
-the newly created tasks. IF the elaboration of one task causes the
-task enclosing it and several others to become completed, is it possible
-that some tasks were activated and others never activated? This new
+However, that covers a multitude of execution during the elaboration of
+the newly created tasks. IF the elaboration of one task causes the
+task enclosing it and several others to become completed, is it possible
+that some tasks were activated and others never activated? This new
wording seems to avoid discussing that case.
> We do have one problem though; a return statement which is exited before the
@@ -1052,76 +1055,76 @@
> initiated begins finalization before the activation of T is initiated, T
> becomes terminated and is never activated.
>
-I don't think you need the first part of this paragraph given the last
+I don't think you need the first part of this paragraph given the last
sentence in (Ada 2007) 9.2(4/2):
-"For tasks that are part or coextensions of a single object that is not
-a stand-alone object, activations are initiated after completing any
-initialization of the outermost object enclosing these tasks, prior to
-performing any other operation on the outermost object. In particular,
-for tasks that are part or coextensions of the object created by the
-evaluation of an allocator
-<http://www.adaic.org/standards/05rm/html/RM-4-8.html#S0129>, the
-activations are initiated as the last step of evaluating the allocator
-<http://www.adaic.org/standards/05rm/html/RM-4-8.html#S0129>, prior to
-returning the new access value. For tasks that are part or coextensions
-of an object that is the result of a function call, the activations are
+"For tasks that are part or coextensions of a single object that is not
+a stand-alone object, activations are initiated after completing any
+initialization of the outermost object enclosing these tasks, prior to
+performing any other operation on the outermost object. In particular,
+for tasks that are part or coextensions of the object created by the
+evaluation of an allocator
+<http://www.adaic.org/standards/05rm/html/RM-4-8.html#S0129>, the
+activations are initiated as the last step of evaluating the allocator
+<http://www.adaic.org/standards/05rm/html/RM-4-8.html#S0129>, prior to
+returning the new access value. For tasks that are part or coextensions
+of an object that is the result of a function call, the activations are
not initiated until after the function returns."
-But the otherwise clause in Randy's proposal again avoids the problem
-case I was worrying about. What happens if one of the created tasks
-raises an exception during its elaboration? It has already started
-activation, and it is possible that several other tasks have as well.
-The task raising the exception becomes a failed task, no problem there.
-But what about the other tasks which may be initiated at the same point
-in the containing task? My read has always been that some tasks may have
-(started and) completed elaboration, and such tasks will not wait for
-all other tasks in the group to complete activation before executing the
+But the otherwise clause in Randy's proposal again avoids the problem
+case I was worrying about. What happens if one of the created tasks
+raises an exception during its elaboration? It has already started
+activation, and it is possible that several other tasks have as well.
+The task raising the exception becomes a failed task, no problem there.
+But what about the other tasks which may be initiated at the same point
+in the containing task? My read has always been that some tasks may have
+(started and) completed elaboration, and such tasks will not wait for
+all other tasks in the group to complete activation before executing the
task body. They exist and are active.
-Later when one of the tasks in the group fails, these tasks will become
-abnormal, then completed etc. It is easy to create a task that takes
-say an hour to elaborate before failing. A (legitimate) implementation
-might do sequential elaboration in that case. But AFAIK, it is not
+Later when one of the tasks in the group fails, these tasks will become
+abnormal, then completed etc. It is easy to create a task that takes
+say an hour to elaborate before failing. A (legitimate) implementation
+might do sequential elaboration in that case. But AFAIK, it is not
required.
-Programmers for today's supercomputers want parallel elaboration of
-tasks. Forget the programming language used for a minute. Distributing
-code to thousands of CPU cores is not easy, and the subject of lots of
-study. We don't want to put artificial barriers in their way. My
-understanding is that in Ada, the activation point is a synchronization
-point for the creator and all the created tasks, but the completion of
-activation is a one way syncronization point. When all the created
-tasks are activated successfully the creating task can proceed. This
-may not seem simple, but in a message passing environment it is about as
-simple as possible. The master task sends out messages telling each
-processor where in the code to begin execution. If that task gets back
-a failure message, it sends out termination messages to all the created
-tasks, otherwise when it gets back the right number of successes, it can
-continue execution. The one to many messages create the most (wall
-clock) overhead, and you want to have just one. If Ada tasks required
-an additional synchronization at the end of activation, that would
-double the number of messages required as part of program initiation.
+Programmers for today's supercomputers want parallel elaboration of
+tasks. Forget the programming language used for a minute. Distributing
+code to thousands of CPU cores is not easy, and the subject of lots of
+study. We don't want to put artificial barriers in their way. My
+understanding is that in Ada, the activation point is a synchronization
+point for the creator and all the created tasks, but the completion of
+activation is a one way syncronization point. When all the created
+tasks are activated successfully the creating task can proceed. This
+may not seem simple, but in a message passing environment it is about as
+simple as possible. The master task sends out messages telling each
+processor where in the code to begin execution. If that task gets back
+a failure message, it sends out termination messages to all the created
+tasks, otherwise when it gets back the right number of successes, it can
+continue execution. The one to many messages create the most (wall
+clock) overhead, and you want to have just one. If Ada tasks required
+an additional synchronization at the end of activation, that would
+double the number of messages required as part of program initiation.
More important, it would add a second one to many message.
-I wrote another post trying to make what I see more visible. Microsoft
-ate it--I left it open overnight without saving a copy, you would have
-thought I would have learned that lesson by now. :-( Anyway, I was
+I wrote another post trying to make what I see more visible. Microsoft
+ate it--I left it open overnight without saving a copy, you would have
+thought I would have learned that lesson by now. :-( Anyway, I was
still trying to get the explanation right:
-When one or more tasks are activated, the activating task, or main
-program, sees activation of a set of tasks as an indivisible operation,
+When one or more tasks are activated, the activating task, or main
+program, sees activation of a set of tasks as an indivisible operation,
which may complete successfully, or raise Tasking_Error.
-The activated task however, each has its own view of time, or progress
-through the program code. Activation of a task at execution time may
-overlap with the activation of other tasks. We had that fight decades
-ago. And if no one remembers the problems caused by sequential
-activation, don't bother to dig out 1982 (I think) papers. The real
-killer was that multiple simultaneous activations could occur in some
+The activated task however, each has its own view of time, or progress
+through the program code. Activation of a task at execution time may
+overlap with the activation of other tasks. We had that fight decades
+ago. And if no one remembers the problems caused by sequential
+activation, don't bother to dig out 1982 (I think) papers. The real
+killer was that multiple simultaneous activations could occur in some
cases anyway, and in any case sequential elaboration had its problems.
-Eventually, it just seemed silly to make an array of task objects a
-special case. (Or a different case from an array of access to task
+Eventually, it just seemed silly to make an array of task objects a
+special case. (Or a different case from an array of access to task
values. ;-)
****************************************************************
@@ -1194,10 +1197,10 @@
From: Robert I. Eachus
Date: Friday, August 3, 2007 7:05 PM
-Totally agree. I originally got torqued out of shape by wording that
-involved that implied that activation of a group of tasks was an
-indivisible act. Of course, it looks that way from the point of view
-of the task doing the activations. It isn't and hasn't been for the
+Totally agree. I originally got torqued out of shape by wording that
+involved that implied that activation of a group of tasks was an
+indivisible act. Of course, it looks that way from the point of view
+of the task doing the activations. It isn't and hasn't been for the
other tasks, and the wording may not have intended to imply that.
****************************************************************
Questions? Ask the ACAA Technical Agent