Equivalence of upc_barrier and upc_notify plus upc_wait

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by johnson....@gmail.com on 13 Mar 2012 at 5:00

[GoogleCodeExporter]

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?

Original comment by w...@uuuuc.us on 16 Mar 2012 at 10:59

[GoogleCodeExporter]

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

Original comment by johnson....@gmail.com on 15 Jun 2012 at 6:02

• Added labels: Milestone-Spec-2.0, Performance

[GoogleCodeExporter]

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

Original comment by danbonachea on 13 Aug 2012 at 5:26

[GoogleCodeExporter]

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

Original comment by phhargr...@lbl.gov on 13 Aug 2012 at 7:18