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

[Former user]

Originally reported on Google Code with ID 51 ``` 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.

```

Reported by `[e-mail]` on 2012-06-11 21:21:58

[Former user]

``` Update summary to better reflect nature of current proposal ```

Reported by `[e-mail]` on 2012-06-14 23:12:23

[Former user]

``` 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. ```

Reported by `danbonachea` on 2012-06-15 00:21:34

[Former user]

``` 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. ```

Reported by `[e-mail]` on 2012-06-15 00:55:52

[Former user]

Reported by `gary.funck` on 2012-07-03 15:10:26 - Labels added: Type-Clarification - Labels removed: Type-Defect

[Former user]

``` "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 ```

Reported by `danbonachea` on 2012-08-16 23:52:07

[Former user]

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

Reported by `danbonachea` on 2012-08-17 15:25:01 - Status changed: `PendingApproval`

[Former user]

``` Set Consensus:High on Pending Approval issues. ```

Reported by `gary.funck` on 2012-08-19 23:31:54 - Labels added: Consensus-High

[Former user]

``` comment #5 applied in SVN r112 ```

Reported by `danbonachea` on 2012-09-14 01:03:30 - Status changed: `Fixed`

[Former user]

``` 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. ```

Reported by `danbonachea` on 2012-09-14 07:26:14

[Former user]

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

Reported by `danbonachea` on 2012-09-14 21:46:01 - Status changed: `Ratified`