13.5.5. Assertions
Up: Synchronization Calls
Next: Miscellaneous Clarifications
Previous: Flush and Sync
The assert argument in the calls
MPI_WIN_POST, MPI_WIN_START,
MPI_WIN_FENCE,
MPI_WIN_LOCK, and MPI_WIN_LOCK_ALL is
used to provide assertions on the context of the call that may be used
to optimize performance. The assert argument does not change
program semantics if it provides correct information on the program---it
is erroneous to provide incorrect information. Users
may always provide
assert = 0 to indicate a general case where no guarantees are made.
Advice to users.
Many implementations may not take advantage of the information in
assert; some of the information is relevant only for
noncoherent shared memory machines. Users
should consult their implementation's manual
to
find which information is useful on each system. On the other hand,
applications that provide correct
assertions whenever applicable are portable and will
take advantage of assertion specific optimizations whenever available.
( End of advice to users.)
Advice
to implementors.
Implementations can always ignore the assert argument.
Implementors should
document which assert values are significant on their
implementation.
( End of advice to implementors.)
assert is the bit vector OR of zero or more of the following
integer constants:
MPI_MODE_NOCHECK, MPI_MODE_NOSTORE,
MPI_MODE_NOPUT,
MPI_MODE_NOPRECEDE, and MPI_MODE_NOSUCCEED.
The significant options are listed below for each synchronization procedure.
Advice to users.
C/C++ users can use bit vector OR (
) to combine these constants;
Fortran 90 users
can use the bit vector IOR intrinsic.
Alternatively, Fortran users can
portably use integer addition to OR the constants (each constant should
appear at most once in the addition).
( End of advice to users.)
-
MPI_WIN_START:
-
-
MPI_MODE_NOCHECK:
-
the
matching calls to MPI_WIN_POST have
already completed on all target processes when the call to
MPI_WIN_START is made.
This option can be
specified in a start call if and only if it is specified in each
matching post call.
This is similar to the optimization
of ``ready-send'' that may save a handshake when the handshake is
implicit in the code.
However, ready-send is matched by a regular receive, whereas
both start and post must specify the MPI_MODE_NOCHECK option.
-
MPI_WIN_POST:
-
-
MPI_MODE_NOCHECK:
-
the
matching calls to MPI_WIN_START
have not yet occurred
on any origin processes when the call to
MPI_WIN_POST is made.
This option can be specified by a post call if and only if it
is specified by each matching start call.
-
MPI_MODE_NOSTORE:
-
the
local window was not updated by
stores (or get or receive operations) since the
last synchronization. This may avoid
the need for cache synchronization during the post call.
-
MPI_MODE_NOPUT:
-
the
local window will not be updated by
put or accumulate
operations after the post call, until the ensuing (wait) synchronization.
This may avoid the need for cache synchronization during the wait call.
-
MPI_WIN_FENCE:
-
-
MPI_MODE_NOSTORE:
-
the
local window was not updated by
stores (or get or receive operations) since the last synchronization.
-
MPI_MODE_NOPUT:
-
the
local window will not be updated
by put or accumulate operations after
the fence call, until the ensuing (fence) synchronization.
-
MPI_MODE_NOPRECEDE:
-
the
fence does not complete any
sequence of RMA operations initiated by the calling MPI process. If this assertion is given by
any MPI process in the group of the window, then it must be given by all
MPI processes in the group.
-
MPI_MODE_NOSUCCEED:
-
the
fence does not start any sequence
of RMA operations initiated by the calling MPI process. If the assertion is given by any MPI process
in the group of the window, then it must be given by all MPI processes in the group.
-
MPI_WIN_LOCK, MPI_WIN_LOCK_ALL:
-
-
MPI_MODE_NOCHECK:
-
no
other MPI process holds, or will attempt
to acquire, a
conflicting lock, while the calling MPI process holds the window lock. This is useful
when
mutual exclusion is achieved by other means, but the coherence operations
that
may be attached to the lock and unlock calls are still required.
Advice to users.
The MPI_MODE_NOSTORE and MPI_MODE_NOPRECEDE options provide
information on what happened before
the call; the MPI_MODE_NOPUT and MPI_MODE_NOSUCCEED
options provide information on what will happen after the call.
( End of advice to users.)
Up: Synchronization Calls
Next: Miscellaneous Clarifications
Previous: Flush and Sync
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