Description
This ticket proposes non-blocking persistent collective operations be added to the standard.
For each API that currently supports a request as an out argument of a non-blocking collective operation, MPI will support an _init version.
Example: MPI_Bcast() [blocking, MPI-1] -> MPI_Ibcast(...,info,request[,ierr]) [MPI 3.x] -> MPI_Bcast_init(...,info,request[,ierr]) [new]
The attached text is prototypical standards draft text.
Some quick notes:
MPI persistent collective operation _inits are initialization calls and follow all the ordering rules already existing for posing nonblocking collective operations (this implies _init operations are local and non-blocking). Remember that the point-to-point init functions disallow communication whereas the persistent collective inits may communicate but must not rely on state of other MPI processes.
The info argument is an in argument that allows for a limited number of hints about how the persistent, nonblocking collective will be used, as defined in the text (collective chapter).
The request argument is an out argument in each process of the calling group of the communicator that can be used zero or more times to start a collective operation. Each such request must be started in all the processes of the underlying group of the communicator (they are deemed active after this). Each request must be completed (making them inactive) before another start is permitted. Each process in the group of the communicator must complete the operation.
We do not require that starts across a group for persistent collective operations serialize to the same order. This makes using MPI_STARTALL allowed.
MPI_Test/MPI_Wait operations (all) give completion information without destroying the persistent request. MPI_Request_free() is used as with persistent point-to-point operations to free up an inactive persistent collective operation. This is the same behavior as for persistent point-to-point requests.
There are some per-communicator info items also defined that make sense on a communicator scope vs. a per-operation scope, also defined in the collective chapter.
Ticket #83 specifies additional functionality for info keys for these persistent operations, and is a related ticket that should be considered in sequence or in parallel with this ticket.
The associated PR is at: https://github.com/mpi-forum/mpi-standard/pull/29
Historical note; you can see the original proposals in the MPI-2 JOD, circa 1997-98: https://www.mpi-forum.org/docs/mpi-jd/mpi-20-jod.ps .