clarification: revise text to eliminate an ambiguity in barrier matching semantics

[GoogleCodeExporter]

As described at
   https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=1228
there is some ambiguity in the current spec with regards to how barrier values 
are matched between the Notify and the Wait, especially when Notify doesn't 
provide a value but Wait does.

A survey of implementations in Aug 2005 showed that four implementations (HP, 
Cray, GCCUPC and Berkeley) had four different interpretations of the corner 
cases.

I am not reproducing the entire text available from the Bugzilla link above.  
However, the "bottom line" is [slightly modified from the Bugzilla text]...

Proposal:

Replace 6.6.1-7 with

If one or more threads provide optional expressions to upc_notify in the 
current synchronization phase, then the upc_wait statement shall interrupt the 
execution of the program in an implementation defined manner if either of the 
following two rules are violated:
    1) All optional expressions provided to upc_notify must have
       equal values (a consensus)
    2) Any optional expression provided to upc_wait must equal
       the consensus value from the upc_notify.
If no thread provides an optional expression to upc_notify, then:
    1) No interruption shall be generated if all provided upc_wait
       values are equal.
    2) Otherwise the behavior is implementation-dependent.

Original issue reported on code.google.com by phhargr...@lbl.gov on 11 Jun 2012 at 9:21

[GoogleCodeExporter]

Update summary to better reflect nature of current proposal

Original comment by phhargr...@lbl.gov on 14 Jun 2012 at 11:12

• Changed title: clarification: revise text to eliminate an ambiguity in barrier matching semantics

[GoogleCodeExporter]

As I'm the originator of this issue, I obviously believe some spec 
clarification is required, especially for the case of { upc_notify MYTHREAD; 
upc_wait; } which I suspect we all agree should generate an error (but does not 
in the current spec).

Regarding Paul's proposed language, my only nitpick is I don't like leaving 
that last case underspecified. I would prefer to simply state that if no thread 
provides an optional expression to upc_notify, then no interruption shall be 
generated. If other implementers favor the flexibility to produce a diagnostic 
in this case (do they?) then the proper "spec-ese" is either 
"implementation-defined" (aka the compiler is required to document the behavior 
it implements) or "unspecified" (aka it could go either way on a case-by-case 
basis).

I would like to hear feedback from other implementers about this clarification 
and implementation impact.

Original comment by danbonachea on 15 Jun 2012 at 12:21

[GoogleCodeExporter]

Dan wrote:
> Regarding Paul's proposed language, my only nitpick [....]

I agree that my "implementation-dependent" should have been 
"implementation-defined", thus requiring each implementation to document their 
behavior for this case.

> I would like to hear feedback from other implementers about this clarification
> and implementation impact. 

I am in favor of "no interruption" for the case that no value is passed to 
upc_notify in any thread, regardless of what value(s) are passed to upc_wait. 
This would replace    "If no thread provides...  implementation-dependent." 
with simply "If no thread provides an optional expression to upc_notify, then 
no interruption shall be generated"

I went with the weaker text because I wasn't being aggressive enough to push my 
interpretation on others.  In particular, I wished to avoid making any spec 
change that would render a current implementation non-conforming without a good 
reason to do so.

Original comment by phhargr...@lbl.gov on 15 Jun 2012 at 12:55

[GoogleCodeExporter]

Original comment by gary.funck on 3 Jul 2012 at 3:10

• Added labels: Type-Clarification
• Removed labels: Type-Defect

[GoogleCodeExporter]

"I went with the weaker text because I wasn't being aggressive enough to push 
my interpretation on others.  In particular, I wished to avoid making any spec 
change that would render a current implementation non-conforming without a good 
reason to do so."

Hearing no comment from any other group on this issue for over a month, I'm 
proposing the stronger wording which explicitly specifies behavior for all 
cases. Realistically, I think all implementations (including BUPC) may require 
minor tweaks to fully conform with the clarified behavior - some don't even 
conform to what 1.2 required. At least this way the required behavior is fully 
and clearly defined.

Proposed Change (omitting changebar markup):
--------------------------------------------------------------------
--- upc-language.tex    (revision 80)
+++ upc-language.tex    (working copy)
@@ -828,14 +831,17 @@
     either the synchronization phase containing the {\tt upc\_notify} or
     the next on different threads.}

-\np The {\tt upc\_wait} statement shall interrupt the execution of
-    the program in an implementation defined manner
-    if the value of its expression differs from the value of
-    the expression on the {\tt upc\_notify} statement issued by any
-    thread in the current
-    synchronization phase.  After such an interruption, subsequent behavior
-    is undefined. No "difference" exists if either statement is missing
-    this optional expression.
+\np If one or more threads provide optional expressions to {\tt upc\_notify} in
+    the current synchronization phase, then the subsequent {\tt upc\_wait} 
statement of at
+    least one thread shall interrupt the execution of the program in an
+    implementation-defined manner if either of the following two rules are 
violated:~%
+    \footnote{After such an interruption, subsequent behavior is undefined.}
+    1) All optional expressions provided to {\tt upc\_notify} must have
+       equal values (a consensus).
+    2) Any optional expression provided to {\tt upc\_wait} must equal
+       the consensus value from the {\tt upc\_notify}.
+    If no thread provides an optional expression to {\tt upc\_notify}, 
+    then no interruption shall be generated.

 %\np The {\tt upc\_wait} statement will generate a runtime
 %    error if the value of its expression differs from any

Original comment by danbonachea on 16 Aug 2012 at 11:52

[GoogleCodeExporter]

Mass-edit to mark all issues with an officially-announced resolution diff as 
"PendingApproval"

Original comment by danbonachea on 17 Aug 2012 at 3:25

• Changed state: PendingApproval

[GoogleCodeExporter]

Set Consensus:High on Pending Approval issues.

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

• Added labels: Consensus-High

[GoogleCodeExporter]

comment #5 applied in SVN r112

Original comment by danbonachea on 14 Sep 2012 at 1:03

• Changed state: Fixed

[GoogleCodeExporter]

For the record:
Public comment period for this change was 8/14/2012 - 9/14/2012
No substantial objections were raised or recorded during that period.
At the 9/7/2012 telecon, it was announced this change was imminent, feedback 
was explicitly solicited, and none was received.
The change was integrated into a working draft distributed on 9/13/2012 for 
consideration and draft ratification at the 9/14/2012 telecon.

Original comment by danbonachea on 14 Sep 2012 at 7:26

[GoogleCodeExporter]

Changes distributed as Draft 1.1 were ratified during the 9/14/2012 
teleconference, for inclusion in the next public draft.

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

• Changed state: Ratified