Amend Initialization Calls of Persistent Collective Communication to be Local

[tonyskjellum]

Problem

The initialization calls of persistent collective collective operations should behave just like nonblocking collective operations" and be local.

Proposal

This change is appropriate for the design, and mirrors the original intent for these operations. Local does not impact order across the group, which is still required.

Changes to the Text

Changes will be made to the Collective Chapter and apply to all persistent collective operations defined in the standard.

Impact on Implementations

Minimal... implementations already support non-blocking collectives and are just starting to work on persistent collective operations.

Impact on Users

None, no legacy code yet. The change is more permissive for applications, not more restrictive.

References

[RolfRabenseifner]

The Persistent WG decided to have collective INIT as blocking, because otherwise MPI_REQUEST_FREE could not be local according to the current progress rule of MPI if we allow that INIT can start internally with some cummunicating optimization protocols. Reason:

• The user is allowed to have zero invocations of START + WAIT/positiveTEST (no free decision, it is a MUST).
• This means INIT+REQUEST_FREE must work (direct implication, therefore also a MUST).
• INIT should be allowed to start some communication for calculating optimizations. (This was a free decision of the WG)
• With the no-deamon-is need MPI progress rule, this implies that
  • either MPI_REQUEST_FREE is blocking (i.e., allowed to synchronize),
  • or we must define that INIT as blocking.

We decided the second one. I do not expect that the working group again wants to restart all this discission. Therefore, I recommend to close this issue.