Info key(s) for Start Ordering Persistent Collective Communication #83
We want to add one or more info keys, such as one that guarantees that the persistent collective operation will only be started in order across the group of its communicator. Other info keys relevant to persistent collective initialization or operations may also be considered in addition to this one.
Note: this ticket actually describes the ordering rules for persistent collectives with and without this assertion with regard to all other collective communication on the same communicator.
Specify at least one info key for ordered-across-group in persistent collectives at communicator scope. Others TBD.
Changes to the Text
Appropriate text will be added that defines the info key and its semantics. If other keys are conceived of quickly, they may be added too. So far, just one info key,
Impact on Implementations
For the specific info key specified thus far, it is an assertion. Implementations can ignore this assertion, or exploit it for greater performance. The assertion is mpi_assert_strict_persistent_collective_ordering ; it requires that programs order persistent collective starts [defined via a communicator that makes this assertion] under the same rules as other collectives. If an implementation can exploit this assertion for greater performance, it can do so, or do legally do nothing.
Impact on Users
Provides an info key; requires that the programs meet the restricted semantics if a given communicator with this assertion is used to generate persistent collective operations.
The pull request for this ticket is mpi-forum/mpi-standard#278
PDF File: mpi40-report-ticket83-12sep20.pdf
The text was updated successfully, but these errors were encountered:
Outcome of reading
Rudiments of the example/counter-examples:
Restrictions with key:
All other ranks must do the exact same dispatch order for these collectives.
Legal --> Other collectives still are issued in same order across group.
We did the reading in San Jose.
The group agrees that we will take ticket 0 votes in Chattanooga on these changes above, which do not change the syntax or semantics of the info key, and then if it passes, take the first vote in Chattanooga in March, 2019. If ticket 0 votes fails, we will re-read in Chattanooga.
We are going to compare with the send+recv explanation in the pt2pt chapter to decide how much to elaborate our example on pp 219-220 of the https://github.com/mpi-forum/mpi-issues/files/2654199/mpi32-report-ticket83-06dec18.pdf draft.