<div dir="ltr">Hey now, blocking doesn't mean that MPI /must/ block, it only means that it /can/ block.  Blocking and synchronizing are certainly not the same; Ssend synchronizes, which is a stronger semantic than blocking.<div>
<br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 12, 2013 at 5:07 PM, 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">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>
<span class="HOEnZb"><font color="#888888"><br>
Jeff<br>
</font></span><div class="HOEnZb"><div class="h5"><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 nonblocking.<br>
> I was not at the Forum.  I pointed out to Wesley after he returned that 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 was<br>
> for a long list of blocking functions: COMM_ACCEPT, COMM_CONNECT, 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 deal<br>
> with concepts, not specific function exceptions. Nonblocking communication<br>
> is one such concept, and it should be valid for all operations (that are not<br>
> local).<br>
><br>
> FWIW, my proposal was only to add nonblocking variants to blocking 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, 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>
</div></div><div class="im HOEnZb">--<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>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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>