[MPI3-IO] shared file pointer
Edgar Gabriel
gabriel at cs.uh.edu
Thu Feb 23 15:45:01 CST 2012
On 2/23/2012 8:49 AM, Rob Latham wrote:
> On Wed, Feb 22, 2012 at 05:25:04PM -0800, Adam T. Moody wrote:
>> I will say, though, given that we can now have multiple outstanding
>> non-blocking collective I/O calls, it would be really nice to be
>> able to do the following:
>
>>
>> MPI_File_iread_ordered()
>> MPI_File_iread_ordered()
>> MPI_File_iread_ordered()
>> MPI_Waitall()
>>
>> This provides a natural way for someone to read in three different
>> sections from a file -- just issue all the calls and sit back and
>> wait. However, this can only be done if the pointer is updated in
>> the initiation call.
>
> Now we're getting somewhere. Setting aside for a moment what the
> letter of MPI-2.2 says, Adam's use case is exactly in line with the
> spirit of shared file pointers.
I would agree, I would like to add one more comment/question: how does
the code sequence listed above compare to
MPI_File_iread_shared()
MPI_File_iread_shared()
MPI_File_iread_shared()
MPI_Waitall()
executed by each process? This is according to my understanding legal in
MPI-2. Wouldn't it be difficult to explain to users that the guarantees
given for this scenario are fundamentally different than when using
MPI_File_iread_ordered?
Thanks
Edgar
> The I/O can happen whenever but the bookeeping -- updating the shared
> file pointer -- happens up front.
>
> ==rob
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 291 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-io/attachments/20120223/281d2d11/attachment-0001.pgp>
More information about the mpiwg-io
mailing list