Equivalence of upc_barrier and upc_notify plus upc_wait

[Former user]

Originally reported on Google Code with ID 5 ``` The equivalence established by 6.6.1.8 requires implementations to support the following code pattern:

if ( ... ) { upc_barrier; } else { upc_notify; do work upc_wait; }

An implementation may have a very efficient mechanism (e.g., hardware) for supporting a barrier which does not support a split-phase barrier. Such an implementation must forgo its optimized barrier for one that is compatible with upc_notify plus upc_wait in order to support the code above. Compiler analysis isn't helpful here because in theory the upc_barrier and the matching upc_notify plus upc_wait could be in different compilation units.

I recommend revising 6.6.1.8 to specify a conceptual equivalence only; matching a upc_barrier with a upc_notify plus upc_wait would become an error. Perhaps this was the original intent of the footnote? The footnote is vague.

```

Reported by `johnson.troy.a` on 2012-03-13 17:00:08

[Former user]

``` Interesting point. The purpose of footnote 23 by my recollection was to not have to define "matching" and "synchronization phase" for upc_barrier which would have been messy. I would not mind expanding the footnote to state that this equivalence does

• not* apply to the requirement that all threads execute the same sequence of collective operations, as stated in section 3.6. We should probably reword the rest of the footnote to be clearer about this.

Anyone have a different recollection on the footnote?

```

Reported by `[e-mail]` on 2012-03-16 10:59:18

[Former user]

``` Milestone 2.0. Would really like to see this changed for performance reasons, but understand that it could break existing codes. ```

Reported by `johnson.troy.a` on 2012-06-15 18:02:54 - Labels added: Milestone-Spec-2.0, Performance

[Former user]

``` "An implementation may have a very efficient mechanism (e.g., hardware) for supporting a barrier which does not support a split-phase barrier."

One implementation mechanism for handling this is to rewrite upc_notify into a strict write (or upc_fence), and rewrite upc_wait into upc_barrier. This makes all barriers blocking and eliminates the possibility for overlapping the barrier latency, but allows you to use the hardware-supported blocking barrier in all cases.

Would this alleviate your concern?

For completeness, here is the text under discussion: "The upc barrier statement is equivalent to the compound statement[23]: { upc_notify barrier_value; upc_wait barrier_value; } where barrier value is the result of evaluating expression if present, otherwise omitted. [23]This equivalence is explicit with respect to matching expressions in semantic 7 and collective status in semantic 3."

"Equivalent" is a very strong statement, which implies the program in comment #0 is valid by 1.2.

The footnote clarifies this equivalence was intended not only to specify the value matching requirements (the first subclause), but also to extend the equivalence of collective operation matching to specify that upc_barrier and upc_notify;upc_wait can be "matched" (the second subclause).

It's worth noting that UPC's requirements for "collective" calls intentionally do not require TEXTUAL matching of collective ops (unlike some other parallel systems), and the intent was to allow matching of barriers in different branches of code (or in different functions, etc). upc_barrier is specified to be interchangeable with upc_notify/upc_wait.

```

Reported by `danbonachea` on 2012-08-13 05:26:27

[Former user]

``` I believe that the spec should remain AS IS with respect to this equivalence.

I think that the right solution is specification of a DISTINCT call for a barrier call that is neither "named" nor split-phase. When I made an attempt to propose that, I was reminded that the Collectives 2.0 proposal already covers that.

So, I move for closure as "NoChange" since we have a proposal which will provide a better solution (and hopefully not later than the 2.0 spec for which this issue is currently targeted). ```

Reported by `[e-mail]` on 2012-08-13 07:18:24