3.9. Progress
Up: MPI Terms and Conventions
Next: Implementation Issues
Previous: Error Handling
MPI communication operations or parallel I/O patterns typically comprise several
related operations executed in one or multiple MPI processes.
Examples are the point-to-point communications with one MPI process executing a
send operation and another (or the same) MPI process executing a receive operation,
or all MPI processes of a group executing a collective operation.
Within each MPI process parts of the communication or parallel I/O pattern are
executed within the MPI procedure calls that belong to the operation in
that MPI process, whereas other parts are
decoupled MPI activities,
i.e., they may be executed within an additional progress thread,
offloaded to the network interface controller (NIC),
or executed within other MPI procedure calls that are not semantically
related to the given communication or parallel I/O pattern.
An MPI procedure invocation is
blocked
if it delays its return until some specific activity
or state-change has occurred in another MPI process.
An MPI procedure call that is blocked can be
- a nonlocal
MPI procedure call that delays its return until a specific
semantically-related MPI call on another MPI process, or
- a local
MPI procedure call that delays its return until some unspecific
MPI call in another MPI process causes a specific state-change in
that other MPI process, or
- an MPI finalization procedure
( MPI_FINALIZE or MPI_SESSION_FINALIZE)
that delays its return or exit because this MPI finalization must guarantee
that all decoupled MPI activities that are related to that MPI finalization call
in the calling MPI process will be executed before this MPI finalization is finished.
Note that an MPI finalization procedure may execute attribute deletion callback functions
prior to the finalization (see Section Allowing User Functions at MPI Finalization);
these callback functions may generate additional decoupled MPI activities.
Some examples of a nonlocal blocked MPI procedure call:
- MPI_SSEND delays its return until the matching receive operation
is started at the destination MPI process (for example, by a call
to MPI_RECV or to MPI_IRECV).
- MPI_RECV delays its return until the matching send operation
is started at the source MPI process (for example, by a call to
MPI_SEND or to MPI_ISEND).
Some examples of a local blocked MPI procedure call:
- MPI_RSEND, if the message data cannot be entirely buffered,
delays its return until the destination MPI process has received the
portion of message data that cannot be buffered, which may require one
or more unspecific MPI procedure call(s) at the destination MPI process.
- MPI_RECV, in case the message was buffered at the sending
MPI process (e.g. with MPI_BSEND), delays its return until
the message is received, which may require one or more unspecific MPI
procedure calls at the sending MPI process to send the buffered data.
All MPI processes are required to
guarantee progress,
i.e., all decoupled MPI activities will eventually be executed.
This guarantee is required to be provided during
- blocked MPI procedures, and
- repeatedly called MPI test procedures (see below) that return flag =false.
The progress must be provided independently of whether a decoupled
MPI activity belongs to a specific session or to the World Model
(see Sections The World Model and The Sessions Model).
Other ways of fulfilling this guarantee are possible and permitted
(for example, a dedicated progress thread or off-loading to a network interface controller (NIC)).
MPI test procedures are
MPI_TEST, MPI_TESTANY, MPI_TESTALL, MPI_TESTSOME,
MPI_IPROBE, MPI_IMPROBE, MPI_REQUEST_GET_STATUS,
MPI_WIN_TEST, and MPI_PARRIVED.
Strong progress
is provided by an MPI implementation if all local procedures return independently
of MPI procedure calls in other MPI processes (operation-related or not).
An MPI implementation provides weak progress
if it does not provide strong progress.
Advice to users.
The type of progress may influence the performance of MPI operations.
A correct MPI application must be written under the assumption that
only weak progress is provided.
Every MPI application that is correct under weak progress will be
correctly executed if strong progress is provided.
In addition, the MPI standard is designed such that correctness under
the assumption of strong progress should imply also correctness if only
weak progress is provided by the implementation.
( End of advice to users.)
Rationale.
MPI does not guarantee progress when using synchronization methods that are not
based on MPI procedures.
Without guaranteed strong progress in MPI this may lead to a deadlock,
see for example Section Processes and
Example Progress in Section Progress.
( End of rationale.)
For further rules, see in Section MPI Procedures the definition of local MPI procedures,
and all references to progress in the
general index.
Up: MPI Terms and Conventions
Next: Implementation Issues
Previous: Error Handling
Return to MPI-4.1 Standard Index
Return to MPI Forum Home Page
(Unofficial) MPI-4.1 of November 2, 2023
HTML Generated on November 19, 2023