Initialization and Completion The call to MPI_FINALIZE should occur on the same thread that initialized MPI. We call this thread the main thread. The call should occur only after all the process threads have completed their MPI calls, and have no pending communications or I/O operations.
Rationale.
This constraint simplifies implementation.
( End of rationale.)
Multiple threads completing the same request. A program where two threads block, waiting on the same
request, is erroneous. Similarly, the same request cannot appear in
the array of requests of two concurrent
MPI_{WAIT|TEST}{ANY|SOME|ALL}
calls.
In MPI, a request can only be completed once. Any combination of
wait or test which violates this rule is erroneous.
This is consistent with the view that a multithreaded execution
corresponds to an interleaving of the MPI calls.
In a single threaded implementation, once a wait is
posted on a request
the request handle will be nullified before it is possible to
post a second wait on the same handle.
With threads, an MPI_WAIT{ANY|SOME|ALL}
may be blocked without having nullified its request(s) so it
becomes the user's responsibility to avoid using the same request
in an MPI_WAIT on another thread.
This constraint also simplifies
implementation, as only one thread will be blocked on any
communication or I/O event.
( End of rationale.)
Probe A receive call that uses source and tag values returned by a preceding
call to MPI_PROBE or MPI_IPROBE will receive the
message matched by the probe call only if there was no other matching
receive
after the probe and before that receive. In a multithreaded
environment, it is up to the user to enforce this condition using
suitable mutual exclusion logic.
This can be enforced by
making sure that each communicator is used by only one thread on each
process.
Collective calls Matching of collective calls on a
communicator, window, or file handle is done according to the order in which the calls are issued
at each process. If concurrent threads issue such calls on the same
communicator, window or file handle, it is up to
the user to make sure the calls are correctly ordered, using
interthread synchronization.
With three concurrent threads in each MPI process of a communicator comm,
it is allowed that thread A in each MPI process calls a collective
operation on comm, thread B calls a file operation on an existing
filehandle that was formerly opened on comm, and thread C invokes one-sided
operations on an existing window handle that was also formerly created
on comm.
( End of advice to users.)
As already specified in MPI_FILE_OPEN and
MPI_WIN_CREATE, a file handle and
a window handle inherit only the group of processes of the underlying
communicator, but not the communicator itself. Accesses to communicators,
window handles and file handles cannot affect one another.
( End of rationale.)
Advice to implementors.
If the implementation of file or window operations internally
uses MPI communication then a duplicated communicator may be cached
on the file or window object.
( End of advice to implementors.)
Exception handlers An exception handler does not necessarily execute in the context of the
thread that made
the exception-raising MPI call; the exception handler may be
executed by a thread that is distinct from the thread that will
return the error code.
The MPI implementation may be multithreaded, so that part of the
communication protocol may execute on a thread that is distinct from
the thread that made the MPI call.
The design allows the exception handler to be executed on the
thread
where the exception occurred.
( End of rationale.)
Interaction with signals and cancellations The outcome is undefined if a thread that executes an MPI call is
cancelled (by another thread), or if a thread catches a signal while
executing an MPI call.
However, a thread of an MPI process may terminate, and may catch
signals or be cancelled by another thread when not executing MPI calls.
Few C library functions are signal safe, and many have cancellation
points --- points where the thread executing them may be cancelled. The
above restriction simplifies implementation (no need for the MPI
library to be ``async-cancel-safe'' or ``async-signal-safe.''
( End of rationale.)
Users can catch signals in separate, non- MPI threads (e.g., by
masking signals on MPI calling threads, and unmasking them in one or
more non- MPI threads).
A good programming practice is to have a distinct thread blocked
in a call to sigwait for each user expected signal that may occur.
Users must not catch signals used by the MPI implementation; as
each MPI implementation is required to document the signals used
internally, users can avoid these signals.
( End of advice to users.)
The MPI library should not invoke library calls that are
not thread safe, if multiple threads execute.
( End of advice to implementors.)
Rationale.
Advice to users.
Rationale.
Advice
to implementors.
Rationale.
Rationale.
Advice to users.
Advice
to implementors.
Up: MPI and Threads
Next: Initialization
Previous: General
Return to MPI-2.1 Standard Index
Return to MPI Forum Home Page
MPI-2.0 of July 1, 2008
HTML Generated on July 6, 2008