[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