9.6.1.0.3 Case 3: $fh_1 \in FH_1$ and $fh_2 \in FH_2$

Consider access to a single file using file handles from distinct collective opens. In order to guarantee sequential consistency, MPI_FILE_SYNC must be used (both opening and closing a file implicitly perform an MPI_FILE_SYNC).

Sequential consistency is guaranteed among accesses to a single file if for any write sequence $SEQ_1$ to the file, there is no sequence $SEQ_2$ to the file which is concurrent with $SEQ_1$. To guarantee sequential consistency when there are write sequences, MPI_FILE_SYNC must be used together with a mechanism that guarantees nonconcurrency of the sequences.

See the examples in Section 9.6.10, page [*], for further clarification of some of these consistency semantics.



MPI_FILE_SET_ATOMICITY(fh, flag)

INOUT
fh file handle (handle)
IN
flag true to set atomic mode, false to set nonatomic mode (logical)

int MPI_File_set_atomicity(MPI_File fh, int flag)



MPI_FILE_SET_ATOMICITY(FH, FLAG, IERROR)INTEGER FH, IERROR
LOGICAL FLAG



int MPI::File::Set_atomicity(bool flag)



void

Let $FH$ be the set of file handles created by one collective open. The consistency semantics for data access operations using $FH$ is set by collectively calling MPI_FILE_SET_ATOMICITY on $FH$. MPI_FILE_SET_ATOMICITY is collective; all processes in the group must pass identical values for fh and flag. If flag is true, atomic mode is set; if flag is false, nonatomic mode is set.

Changing the consistency semantics for an open file only affects new data accesses. All completed data accesses are guaranteed to abide by the consistency semantics in effect during their execution. Nonblocking data accesses and split collective operations that have not completed (e.g., via MPI_WAIT) are only guaranteed to abide by nonatomic mode consistency semantics.

Advice to implementors. Since the semantics guaranteed by atomic mode are stronger than those guaranteed by nonatomic mode, an implementation is free to adhere to the more stringent atomic mode semantics for outstanding requests.(End of advice to implementors.)



MPI_FILE_GET_ATOMICITY(fh, flag)

IN
fh file handle (handle)
OUT
flag true if atomic mode, false if nonatomic mode (logical)

int MPI_File_get_atomicity(MPI_File fh, int *flag)



MPI_FILE_GET_ATOMICITY(FH, FLAG, IERROR)INTEGER FH, IERROR
LOGICAL FLAG



int MPI::File::Get_atomicity() const



bool

MPI_FILE_GET_ATOMICITY returns the current consistency semantics for data access operations on the set of file handles created by one collective open. If flag is true, atomic mode is enabled; if flag is false, nonatomic mode is enabled.



MPI_FILE_SYNC(fh)

INOUT
fh file handle (handle)

int MPI_File_sync(MPI_File fh)



MPI_FILE_SYNC(FH, IERROR)INTEGER FH, IERROR



int MPI::File::Sync()



void

Calling MPI_FILE_SYNC with fh causes all previous writes to fh by the calling process to be transferred to the storage device. If other processes have made updates to the storage device, then all such updates become visible to subsequent reads of fh by the calling process. MPI_FILE_SYNC may be necessary to ensure sequential consistency in certain cases (see above).

MPI_FILE_SYNC is a collective operation.

The user is responsible for ensuring that all nonblocking requests and split collective operations on fh have been completed before calling MPI_FILE_SYNC--otherwise, the call to MPI_FILE_SYNC is erroneous.

MPI-Standard for MARMOT