<div dir="ltr">Jeff,<div><br></div><div style>How would iwin_flush be different in practice from doing nothing?  I can give you a trivial implementation that does nothing until you wait on the request, at which point I call blocking win_flush.  With my implementor hat on, I would view this function as a performance hint that indicates to the implementation that you will want to complete all operations thus far and none after.  Given a high quality implementation that actually makes background progress on one-sided communications, this should be unnecessary and I would probably implement it as above.  If you want to only complete specific operations, the request generating functions are available.</div>
<div style><br></div><div style> ~Jim.</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 11:09 AM, Jeff Hammond <span dir="ltr"><<a href="mailto:jhammond@alcf.anl.gov" target="_blank">jhammond@alcf.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, I was making a disingenuous argument to push back against the<br>
fallacy that iwin_flush is not required.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jeff<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Jun 14, 2013 at 10:25 AM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br>
> Hey now, blocking doesn't mean that MPI /must/ block, it only means that it<br>
> /can/ block.  Blocking and synchronizing are certainly not the same; Ssend<br>
> synchronizes, which is a stronger semantic than blocking.<br>
><br>
>  ~Jim.<br>
><br>
><br>
> On Wed, Jun 12, 2013 at 5:07 PM, Jeff Hammond <<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a>> wrote:<br>
>><br>
>> Sure, let's separate these issues.  I think Pirate RMA (RRPUT,<br>
>> RRACCUMULATE and RRRGET_ACCUMULATE) is a more _local_ solution in the<br>
>> MPI standard sense :-)<br>
>><br>
>> SEND is also a nonblocking operation because the implementation can<br>
>> always buffer the data and return before the remote RECV is posted.<br>
>> Only SSEND is blocking if one asserts that blocking is equivalent to<br>
>> "requires remote agency to complete".<br>
>><br>
>> So basically, I completely agree with the Forum back-pushers that<br>
>> IWIN_FLUSH etc. are as useful as ISEND.<br>
>><br>
>> Jeff<br>
>><br>
>> On Wed, Jun 12, 2013 at 4:58 PM, Pavan Balaji <<a href="mailto:balaji@mcs.anl.gov">balaji@mcs.anl.gov</a>> wrote:<br>
>> ><br>
>> > The push-back at the Forum was that WIN_FLUSH and WIN_UNLOCK are local<br>
>> > operations (in MPI's definition of local), so they are already<br>
>> > nonblocking.<br>
>> > I was not at the Forum.  I pointed out to Wesley after he returned that<br>
>> > they<br>
>> > are only local in the simple case where no one else is holding the lock.<br>
>> > Otherwise they are not.<br>
>> ><br>
>> > Further, the proposal is not only about WIN_FLUSH and WIN_UNLOCK.  It<br>
>> > was<br>
>> > for a long list of blocking functions: COMM_ACCEPT, COMM_CONNECT,<br>
>> > WIN_FENCE,<br>
>> > WIN_COMPLETE, WIN_WAIT, WIN_UNLOCK, WIN_FLUSH, WIN_FLUSH_LOCAL,<br>
>> > WIN_FLUSH_ALL, WIN_FLUSH_LOCAL_ALL, ...  The point was that MPI should<br>
>> > deal<br>
>> > with concepts, not specific function exceptions. Nonblocking<br>
>> > communication<br>
>> > is one such concept, and it should be valid for all operations (that are<br>
>> > not<br>
>> > local).<br>
>> ><br>
>> > FWIW, my proposal was only to add nonblocking variants to blocking<br>
>> > calls.<br>
>> > Adding extra per-op remote completion requests is a separate issue and<br>
>> > should not be mixed with this.  I personally think it's useful (in fact,<br>
>> > my<br>
>> > original proposal for RPUT/RGET equivalents had it), but that's still a<br>
>> > separate issue.<br>
>> ><br>
>> >  -- Pavan<br>
>> ><br>
>> ><br>
>> > On 06/12/2013 09:41 AM, Jeff Hammond wrote:<br>
>> >><br>
>> >> So Wes was telling me about IWIN_FLUSH yesterday (this function is a<br>
>> >> great idea, btw) and the alternative of adding double-request RPUT and<br>
>> >> RACCUMULATE that provide a request for both local and remote<br>
>> >> completion.  By induction, this would imply a triple-request<br>
>> >> RGET_ACCUMULATE operation, which I also think is a good idea.  It's<br>
>> >> really silly to have to wait for the result buffer to be ready to<br>
>> >> reuse the origin buffer in RGET_ACCUMULATE.  It seems that many<br>
>> >> implementations will be able to send the entire origin buffer a<br>
>> >> nontrivial amount of time before the result comes back, particularly<br>
>> >> if the remote side doesn't have hardware-based progress and the data<br>
>> >> has to wait in a network buffer.<br>
>> >><br>
>> >> I'm sorry that I missed the last day of the Forum in San Jose.  I<br>
>> >> didn't know these operations were on the table.  They sound like a<br>
>> >> great idea to me.<br>
>> >><br>
>> >> Jeff<br>
>> >><br>
>> ><br>
>> > --<br>
>> > Pavan Balaji<br>
>> > <a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jeff Hammond<br>
>> Argonne Leadership Computing Facility<br>
>> University of Chicago Computation Institute<br>
>> <a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / (630) 252-5381<br>
>> <a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
>> <a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
>> ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
>> _______________________________________________<br>
>> mpi3-rma mailing list<br>
>> <a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> mpi3-rma mailing list<br>
> <a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
<br>
<br>
<br>
--<br>
Jeff Hammond<br>
Argonne Leadership Computing Facility<br>
University of Chicago Computation Institute<br>
<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / (630) 252-5381<br>
<a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
<a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
_______________________________________________<br>
mpi3-rma mailing list<br>
<a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
</div></div></blockquote></div><br></div>