13.5.5. Assertions

PreviousUpNext
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 (Image file ) 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.)


PreviousUpNext
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