Hi, when I developped our I/O routines, I did had to end any split collective call on a file before starting a new one, and it is said to do so: On any MPI process, each file handle may have at most one active split collective operation at any time. here: http://mpi.deino.net/mpi_functions/MPI_File_read_at_all_begin.html Hope this help... Eric Le 18-02-16 à 16:14, Thakur, Rajeev a écrit :
In Section 13.4.1, under Positioning (pg 507 of MPI 3.1), it says
"In a nonblocking or split collective operation, the pointer is updated by the call that initiates the I/O”
So the file pointer is updated after each call to MPI_File_iread_all. This function uses the individual (local to each process) file pointer, so it should be independent of the number of ranks. If you are seeing some other behavior, it would be useful if you can send a small test program.
Rajeev
On Feb 6, 2018, at 9:07 AM, Martin Pokorny <[email protected]> wrote:
I originally posted the following to the mpi-forum mailing list, but have not received a reply. Perhaps someone on this list can help me out.
I'd like to ask for some clarification on the expected outcome of a sequence of calls to non-blocking MPI-IO functions on a single file handle. To be concrete, assume a sequence of calls to MPI_File_iread_all(). My question concerns the result of making a new request before a previous request has completed. Sec 13.6.5 of the standard says "The call initiates the operation which may progress independently of any communication, computation, or I/O.", which could be interpreted to mean there's no guarantee that the second call will start reading from the position of the file pointer after the completion of the previous request. In some testing that I've done, when one request does not wait for the previous request to complete, I get inconsistent results in the sense that the following read does or does not start from the file pointer position at the completion of the previous read (seeming to depend on the number of ranks, but there could be more to that effect). I'm uncertain whether the inconsistency that I'm seeing is to be expected, or might point to a bug in the MPI library implementation.
-- Martin Pokorny Software Engineer Jansky Very Large Array correlator back-end and CASA software National Radio Astronomy Observatory - New Mexico Operations _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss