<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Mohamad,<div><br><div><div>On Feb 12, 2012, at 11:52 AM, Mohamad Chaarawi wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Hi All,<br>
<br>
So after laying out these choices, I see 3 options for the nbcio
ticket:<br>
<br>
1) Keep it the way it is, and adding an advise to users saying that
intermixing nonblocking collective shared fp operation and
independent shared fp operations is undefined.<br>
<br>
2) Make the previous case illegal.<br>
<br>
3) remove the nonblocking ordered operations from this ticket (to be
handled in a separate ticket)<br>
<br>
keep in mind, as mentioned previously, we can't provide a prototype
implementation for those routines. From our side, if the forum
accepts only a pseudo code implementation for those routines, we
would like to proceed with option 1, otherwise we would go with
option 3.<br></div></blockquote><div><br></div><span class="Apple-tab-span" style="white-space:pre"> </span>Sounds good to me.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Quincey</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
Any other opinions?<br>
<br>
Thanks,<br>
Mohamad<br>
<br>
On 2/6/2012 1:19 PM, Dries Kimpe wrote:
<blockquote cite="mid:20120206191941.GC26457@today.mcs.anl.gov" type="cite">
<pre wrap="">Yes, that's an accurate summary.
Dries
* Mohamad Chaarawi <a class="moz-txt-link-rfc2396E" href="mailto:chaarawi@hdfgroup.org"><chaarawi@hdfgroup.org></a> [2012-02-06 10:48:50]:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Dries,
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">I'm jumping late on this thread, but to summarize so far (and correct me
if I made a mistake understanding), we have two cases:
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">1) two non-blocking collective shared FP operations:
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap=""> MPI_File_iread_ordered
MPI_File_iread_ordered
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">This will be ordered in the sense that the user will see that the first
operations will occur before the second one.
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">2) mixed collective and independent
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap=""> MPI_File_iread_ordered
MPI_File_read_shared
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Where the choices that you mentioned apply, right?
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap=""> * make that case illegal
* make it undefined
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">As you mentioned that since the split collectives leave it as undefined,
makes me lean more towards keeping it that way.
</pre>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Thanks,
Mohamad
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On 02/02/2012 04:22 PM, Dries Kimpe wrote:
</pre>
<blockquote type="cite">
<pre wrap="">There might be some use in 'undefined ordering' as opposed to 'illegal'
for those application that don't care about the ordering.
</pre>
</blockquote>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Applications that do rely on the ordering can easily use the existing MPI
functions to enforce ordering.
</pre>
</blockquote>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So, the way I see it: 2 choices:
1) Say order is undefined in the standard (basically there's a precedent
with the split collective versions).
2) Say it is illegal. The user can duplicate the file handle and easily
implement their own version of what they need.
</pre>
</blockquote>
</blockquote>
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(2) is easier for the implementor.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
MPI3-IO mailing list
<a class="moz-txt-link-abbreviated" href="mailto:MPI3-IO@lists.mpi-forum.org">MPI3-IO@lists.mpi-forum.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io</a>
</pre>
</blockquote>
<pre wrap=""></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
MPI3-IO mailing list
<a class="moz-txt-link-abbreviated" href="mailto:MPI3-IO@lists.mpi-forum.org">MPI3-IO@lists.mpi-forum.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>MPI3-IO mailing list<br><a href="mailto:MPI3-IO@lists.mpi-forum.org">MPI3-IO@lists.mpi-forum.org</a><br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io<br></blockquote></div><br></div></body></html>