[mpich-discuss] nonblocking I/O sequence

[Éric Chamberland]

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 <mpokorny at nrao.edu> 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     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20180216/9e4bc0e3/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss