CVS difference for ais/ai-00118.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00118.txt

--- ais/ai-00118.txt	1998/09/30 00:17:19	1.1
+++ ais/ai-00118.txt	1999/07/29 00:51:01	1.2
@@ -1,5 +1,6 @@
-!standard 09.10    (11)                               96-11-16  AI95-00118/03
+!standard 09.10    (11)                               99-07-28  AI95-00118/04
 !class binding interpretation 96-04-04
+!status Corrigendum 2000 99-07-28
 !status WG9 approved 96-12-07
 !status ARG approved 9-0-3  96-10-07
 !status work item (letter ballot requested and failed) 96-09-15
@@ -10,12 +11,12 @@
 !difficulty Hard
 !subject Termination signals query of Terminate attribute
 
-!summary 96-07-23
+!summary
 
 A task T2 can rely on values of variables that are updated by another
 task T1, if task T2 first verifies that T1'Terminated is True.
 
-!question 96-10-07
+!question
 
 Consider:
 
@@ -30,7 +31,7 @@
        end T1;
 
     begin
-       loop 
+       loop
 	  if Local_Task'Terminated then
 	     Rely_On(Stop_Pulse=17); -- Is this erroneous?  (No.)
 	     exit;
@@ -41,19 +42,19 @@
 Since there is no signaling as per 9.10(2-10) between the assignment to
 Stop_Pulse and any action in task T prior to the call on Rely_On, reliance
 on the update to Stop_Pulse by Local_Task is erroneous by 9.10(11).
-9.10(6) doesn't apply, since T is not yet (or ever) waiting for the 
+9.10(6) doesn't apply, since T is not yet (or ever) waiting for the
 termination of Local_Task in the Ada technical sense of "waiting".
 
-!recommendation 96-04-04
+!recommendation
 
 (See summary.)
 
-!wording 96-07-23
+!wording
 
 An action A1 signals an action A2 if A1 is the termination of a task T,
 and A2 is the evaluation of the expression T'Terminated.
 
-!discussion 96-09-15
+!discussion
 
 It would be surprising if T'Terminated were True, but T failed to update
 any locally-cached variables, or the querying task failed to see those
@@ -62,8 +63,22 @@
 Note that we do not say anything about the Callable attribute; if the
 Callable attribute becomes False, the task might still have a local
 cache that is out of sync with global variables.
+
+!corrigendum 9.10(7)
+
+@dinsa
+@xbullet<If A1 is part of the execution of a task, and A2 is the action of
+waiting for the termination of the task;>
+@dinst
+@xbullet<An action A1 signals an action A2 if A1 is the termination of a task T, and A2
+is the evaluation of the expression T'Terminated;>
+
+!ACATS test
+
+It is possible to write a test for the example given here, but it probablt
+would work even for an incorrect implementation.
 
-!appendix 96-04-04
+!appendix
 
 !section 9.10(11)
 !subject signaling concept may be incomplete
@@ -85,7 +100,7 @@
  end T1;
 
 begin
- loop 
+ loop
     if Local_Task'Terminated then
        Rely_on(Stop_Pulse=17);      -- you better not.
        exit;
@@ -95,7 +110,7 @@
 Since there is no signaling as per 9.10(2-10) between the assignment to
 Stop_Pulse and any action in task T prior to the call on Rely_On, reliance
 on the update to Stop_Pulse by Local_Task is erroneous by 9.10(11).
-9.10(6) doesn't apply, since T is not yet (or ever) waiting for the 
+9.10(6) doesn't apply, since T is not yet (or ever) waiting for the
 termination of Local_Task in the Ada technical sense of "waiting".
 
 Clearly, one would like this idiom to work as "expected" and shared
@@ -126,28 +141,28 @@
 > variables, whose changed values are cached by the implementation of local
 > tasks, to be updated upon termination at the latest.
 
-Why is it so important? I mean, why is it so "clear"?  Since Ada does not 
-provide a way to really wait on a termination of another task (if we exclude 
-the business of masters which is another issue), only to query the 
-'terminated attribute, I don't see where spin-waiting will be the practical 
-way to achieve that. With a simple PO, you can get the same result, 
-admittedly with more overhead, but I think that in a real life example, 
-using a PO will be much more realistic.  So to summarize, I am interested to 
+Why is it so important? I mean, why is it so "clear"?  Since Ada does not
+provide a way to really wait on a termination of another task (if we exclude
+the business of masters which is another issue), only to query the
+'terminated attribute, I don't see where spin-waiting will be the practical
+way to achieve that. With a simple PO, you can get the same result,
+admittedly with more overhead, but I think that in a real life example,
+using a PO will be much more realistic.  So to summarize, I am interested to
 know why you find this example so useful?
 
-On the implementation side, there is (admittedly small) penalty for doing 
-what you ask for.  If the reason that Stop_Pulse is not safely available to 
-T is becuase it is in a register, it is practically guaranteed that when 
-Local_Task terminates. all the register-variables (those which are visible 
-to other tasks), will be flushed back to memory.  No problem here.  But your 
-example suggests that you were thinking of a multi-processor, presumably 
-with enough processors so you don't care of dedicating one for the 
-spin-wait. In these cases we have to think about non-consistent caches. 
-Unless the implementatation keeps a "good" (i.e. quite elaborate) track of 
-all the global variables that the task touches, the entire cache will have 
-to be flushed to the real memory when the task terminates.  (I may be wrong 
-here, but I think that most such caches don't allow you to flush individual 
-words. They usually flush the entire cache or regions of it.)  Just a 
+On the implementation side, there is (admittedly small) penalty for doing
+what you ask for.  If the reason that Stop_Pulse is not safely available to
+T is becuase it is in a register, it is practically guaranteed that when
+Local_Task terminates. all the register-variables (those which are visible
+to other tasks), will be flushed back to memory.  No problem here.  But your
+example suggests that you were thinking of a multi-processor, presumably
+with enough processors so you don't care of dedicating one for the
+spin-wait. In these cases we have to think about non-consistent caches.
+Unless the implementatation keeps a "good" (i.e. quite elaborate) track of
+all the global variables that the task touches, the entire cache will have
+to be flushed to the real memory when the task terminates.  (I may be wrong
+here, but I think that most such caches don't allow you to flush individual
+words. They usually flush the entire cache or regions of it.)  Just a
 thought.
 
 Offer Pazy
@@ -170,13 +185,13 @@
 !discussion
 
 Offer writes:
-> If the reason that Stop_Pulse is not safely available to 
-> T is becuase it is in a register, it is practically guaranteed that when 
-> Local_Task terminates. all the register-variables (those which are visible 
-> to other tasks), will be flushed back to memory.  No problem here. 
+> If the reason that Stop_Pulse is not safely available to
+> T is becuase it is in a register, it is practically guaranteed that when
+> Local_Task terminates. all the register-variables (those which are visible
+> to other tasks), will be flushed back to memory.  No problem here.
 
 What makes you so sure ?  (This is actually where my problem started, even
-if the comment cast it in terms of 'TERMINATED.) 
+if the comment cast it in terms of 'TERMINATED.)
 In terms of language rules, there doesn't seem to be any such guarantee,
 unless the local task completes via a terminate alternative (to engage ARM
 9.10(6)) AND the master has finalization code to execute (to be able to
@@ -184,11 +199,11 @@
 slave's termination) AND that finalization code references the shared
 variable.
 
-> Why is it so important? I mean, why is it so "clear"? 
+> Why is it so important? I mean, why is it so "clear"?
 Admittedly, I'm not sure. Of course, using a PO solves the problem. But
-really, the 'TERMINATED example comes as a bit of a surprise, if the 
+really, the 'TERMINATED example comes as a bit of a surprise, if the
 answer is that there are circumstances where I cannot expect that updates
-to shared variables have happened by the time the task has terminated. 
+to shared variables have happened by the time the task has terminated.
 
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent