Correct example 2 in the UPC specification in the discussion of upc_forall

[GoogleCodeExporter]

This proposal is responsive to issue 45.

45. Correct example 2 in the UPC specification in the discussion of upc_forall. 
 See: https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=2985.

The cited bug report has the following text.

bug2690 contains a version of Example 2 from the UPC spec v1.2.

The spec is very clear that the test expression in the upc_forall() will be 
evaluated 10 times.  However, the output shown in the report for bug 2690 (and 
from the version in our test suite) shows it has been evaluated 11 times.

If one looks at the C spec, one finds that the test expression is evaluated 
BEFORE each of the 10 loop iterations and a final 11th time to terminate the 
loop.  It appears that the UPC spec is either "wrong" (or perhaps just poorly 
worded).

The example reads as follows (6.6.2.15):

EXAMPLE 2: Evaluation of upc forall arguments:

  int i;
  upc_forall((foo1(), i=0); (foo2(), i<10);
              (foo3(), i++); i) {
    foo4(i);
  }

Each thread evaluates foo1() exactly once, before any further action on that 
thread. Each thread will execute foo2() and foo3() in alternating sequence, 10 
times on each thread. Assuming there is no enclosing upc forall loop, foo4() 
will be evaluated exactly 10 times total before the last thread exits the loop, 
once with each of i=0..9. Evaluations of foo4() may occur on different threads 
(as determined by the affinity clause) with no implied synchronization or 
serialization between foo4() evaluations or controlling expressions on 
different threads. The final value of i is 10 on all threads.

This proposal recommends that this sentence:
"Each thread will execute foo2() and foo3() in alternating sequence, 10
times on each thread."
be rewritten as follows:
"Each thred will execute foo2() and foo3() 11 times (once for each value of i 
in the range 0..10)."

Original issue reported on code.google.com by gary.funck on 21 May 2012 at 11:52

[GoogleCodeExporter]

I agree with the proposed replacement text (except the misspelling of 
"thread"), but would like to consider bringing back the "alternating" language. 
 I am not sure if it adds much, but the meaning it conveyed was very clear to 
me.

Original comment by phhargr...@lbl.gov on 22 May 2012 at 1:05

[GoogleCodeExporter]

Original comment by phhargr...@lbl.gov on 1 Jun 2012 at 3:52

• Added labels: Spec-1.3

[GoogleCodeExporter]

Original comment by phhargr...@lbl.gov on 1 Jun 2012 at 6:07

• Added labels: Milestone-Spec-1.3
• Removed labels: Spec-1.3

[GoogleCodeExporter]

I believe the proposed wording is also incorrect. Here is the exact sequence 
for a given thread:

value of i     functions executed
==========     ==================
               foo1()
i=0
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=1
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=2
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=3
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=4
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=5
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=6
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=7
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=8
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=9
               foo2() (loop test)
               foo4() (body, if this thread has affinity)
               foo3() (increment)
i=10
               foo2() (loop test)
               LOOP EXITS

Counting the above, the foo3() increment is executed TEN times (incrementing i 
from 0 to 10), and the foo2() loop test is executed ELEVEN times (the final 
test being the one terminating the loop).

Amended proposal recommends that this sentence:

"Each thread will execute foo2() and foo3() in alternating sequence, 10
times on each thread."

be rewritten as follows:

"Each thread will execute foo2() and foo3() in alternating sequence, 10 times 
on each thread, followed by a final call to foo2() on each thread before the 
loop terminates."

Original comment by danbonachea on 12 Aug 2012 at 7:27

[GoogleCodeExporter]

Set default Consensus to "Low".

Original comment by gary.funck on 19 Aug 2012 at 11:26

• Added labels: Consensus-Low

[GoogleCodeExporter]

Change Status to New: Requires review.

Original comment by gary.funck on 19 Aug 2012 at 11:37

• Changed state: New

[GoogleCodeExporter]

I'm claiming ownership of this issue.

Original comment by danbonachea on 14 Sep 2012 at 9:28

• Changed state: Accepted

[GoogleCodeExporter]

Change proposal officially announced on 9/16/12:

--- upc-language.tex    (revision 115)
+++ upc-language.tex    (working copy)
@@ -1034,7 +1034,9 @@
 \end{verbatim}
    Each thread evaluates foo1() exactly once, before any further action on that
    thread. Each thread will execute foo2() and foo3() in alternating sequence,
-   10 times on each thread. Assuming there is no enclosing upc\_forall loop, 
+   10 times on each thread,
+   \xadded[id=DB]{29}{followed by a final call to foo2() on each thread before 
the loop terminates.}
+   Assuming there is no enclosing upc\_forall loop, 
    foo4() will be evaluated exactly 10 times total before the last thread exits the
    loop, once with each of i=0..9. Evaluations of foo4() may occur on different
    threads (as determined by the affinity clause) with no implied synchronization

Original comment by danbonachea on 16 Sep 2012 at 10:20

• Changed state: PendingApproval
• Added labels: Consensus-High
• Removed labels: Consensus-Low

[GoogleCodeExporter]

This PendingApproval issue was ratified at the 10/19/2012 telecon, and merged 
into the working draft in SVN 175.

Original comment by danbonachea on 22 Oct 2012 at 6:43

• Changed state: Ratified