15.6.11. Examples

PreviousUpNext
Up: Consistency and Semantics Next: Asynchronous I/O Previous: File Size

The examples in this section illustrate the application of the MPI consistency and semantics guarantees. These address


The simplest way to achieve consistency for conflicting accesses is to obtain sequential consistency by setting atomic mode.
Example For the code below, process 1 will read either 0 or 10 integers. If the latter, every element of b will be 5. If nonatomic mode is set, the results of the read are undefined.

Image file

Image file

A user may guarantee that the write on process 0 precedes the read on process 1 by imposing temporal order with, for example, calls to MPI_BARRIER.


Advice to users.

Routines other than MPI_BARRIER may be used to impose temporal order. In the example above, process 0 could use MPI_SEND to send a 0 byte message, received by process 1 using MPI_RECV. ( End of advice to users.)

Example Alternatively, a user can impose consistency with nonatomic mode set:

Image file

Image file

The ``sync-barrier-sync'' construct is required because:



Example The following program represents an erroneous attempt to achieve consistency by eliminating the apparently superfluous second ``sync'' call for each process.

Image file

Image file

The above program also violates the MPI rule against out-of-order collective operations and will deadlock for implementations in which MPI_FILE_SYNC blocks.


Advice to users.

Some implementations may choose to implement MPI_FILE_SYNC as a temporally synchronizing function. When using such an implementation, the ``sync-barrier-sync'' construct above can be replaced by a single ``sync.'' The results of using such code with an implementation for which MPI_FILE_SYNC is not temporally synchronizing is undefined. ( End of advice to users.)


PreviousUpNext
Up: Consistency and Semantics Next: Asynchronous I/O Previous: File Size


15.6.11.1. Asynchronous I/O

PreviousUpNext
Up: Examples Next: I/O Error Handling Previous: Examples

The behavior of asynchronous I/O operations is determined by applying the rules specified above for synchronous I/O operations.


Example The following examples all access a preexisting file ``myfile.'' Word 10 in myfile initially contains the integer 2. Each example writes and reads word 10.

First consider the following code fragment:

Image file

For asynchronous data access operations, MPI specifies that the access occurs at any time between the call to the asynchronous data access routine and the return from the corresponding request complete routine. Thus, executing either the read before the write, or the write before the read is consistent with program order. If atomic mode is set, then MPI guarantees sequential consistency, and the program will read either 2 or 4 into b. If atomic mode is not set, then sequential consistency is not guaranteed and the program may read something other than 2 or 4 due to the conflicting data access.

Similarly, the following code fragment does not order file accesses:

Image file

If atomic mode is set, either 2 or 4 will be read into b. Again, MPI does not guarantee sequential consistency in nonatomic mode.

On the other hand, the following code fragment:

Image file

defines the same ordering as:

Image file

Since


MPI guarantees that both program fragments will read the value 4 into b. There is no need to set atomic mode for this example.

Similar considerations apply to conflicting accesses of the form:

Image file

In addition, as mentioned in Section Nonblocking Collective File Operations, nonblocking collective I/O operations have to be called in the same order on the file handle by all processes.

Similar considerations apply to conflicting accesses of the form:

Image file

Recall that constraints governing consistency and semantics are not relevant to the following:

Image file

since split collective operations on the same file handle may not overlap (see Section Split Collective Data Access Routines).


PreviousUpNext
Up: Examples Next: I/O Error Handling Previous: Examples


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