[MPI3-IO] Updated draft for ticket 273
Mohamad Chaarawi
chaarawi at hdfgroup.org
Fri Feb 24 10:39:09 CST 2012
Hi All,
After the comments on and off list about the shared file pointer
operations, and specifically about when the shared file pointer will be
updated, I'm finding it more compelling now to actually maintain the
order in which the shared file pointer is updated. This will make the
nonblocking collective and independent shared file pointer operations
non local, but in theory, as Edgar pointed out to me, all shared file
pointer operations can be non local anyhow.
So I took out the Advice to Users that mentions that mixing collective
and independent operations is undefined, and added this to the
consistency semantics section for nonblocking collective I/O operations:
All nonblocking collective I/O calls are local and return immediately,
irrespective of the status of other
processes. The shared file pointer operations are an exception, because
updating the shared file pointer might be a non local operation.
I guess this would be the "right" thing to do, and the original intent
for the split collective routines as Adam pointed out, despite the
contradiction in the standard.
The updated draft is attached to the ticket url
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/273
Thanks,
Mohamad
On 02/15/2012 05:39 PM, Quincey Koziol wrote:
> Hi Mohamad,
> One small comment about the change to lines 38-43 on p484: this
> sentence: "All processes, belonging to the group of the communicator
> that was used to open the file, must call collective I/O operations
> (blocking and nonblocking) in the same order." doesn't need any
> commas. Also, I would probably add the same advise to users for
> MPI_FILE_IWRITE_ORDERED as you added for MPI_FILE_IREAD_ORDERED.
>
> Otherwise, looks good to me, :-)
>
> Quincey
>
> On Feb 15, 2012, at 2:37 PM, Mohamad Chaarawi wrote:
>
>> Hi All,
>>
>> I attached to the ticket
>> (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/273) the updated
>> draft with the suggested ticket 0 changes from the reading at the
>> last meeting.
>>
>> For your convenience, here are the changes made to the text including
>> the page number:
>>
>> *
>> p:444 We should make table 13.1 have three rows: blocking, nonblocking& split collective, along with marking the split collectives as deprecated in the table (if possible). (ticket 0)
>> *
>> p:451 (line 21), 456 (line 40), 463 (line 21) We need to change the 'void *' buffer parameters for the "write" routines to be 'const void *'.
>> *
>> p: 484 (line 46) "Quality" should be "High Quality".
>> *
>> p: 484 (line 38-43) The sentence ending with "in between" needs editing to indicate what the collective operations are "between".
>> o I rephrased this sentence a little and added a reference to
>> the collective semantics.
>> *
>> p: 484 (line 36) "belonging to the communicator" should be "belonging to the group of the communicator".
>> *
>> p: 484 (line 48) "All calls" should be changed to "All nonblocking collective I/O calls".
>> *
>> p: 445 (line 25) The sentence "In a nonblocking or split collective operation, the pointer is updated by the call that initiates the I/O, possibly before the access completes." should have a note about the split collectives being deprecated.
>> *
>> p"462 (line 28) Add advice to users to indicate the result of intermixing nonblocking collective and independent shared file pointer operations is undefined
>>
>> Please let me know if you have any comments about the changes.
>>
>> Thanks,
>> Mohamad
>>
>> _______________________________________________
>> MPI3-IO mailing list
>> MPI3-IO at lists.mpi-forum.org <mailto:MPI3-IO at lists.mpi-forum.org>
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io
>
>
>
> _______________________________________________
> MPI3-IO mailing list
> MPI3-IO at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-io/attachments/20120224/572adca7/attachment-0001.html>
More information about the mpiwg-io
mailing list