<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'><div><span style="font-size: 12pt;">For the Iprob, the case I'm considering is indeed the one where a process has to do non-blocking sends and non-blocking receives of undefined lengths; I ended up with two options: 1) using a busy loop that does an MPI_Testany for the list of send requests and a series of MPI_Iprob for a list of (source,tag) pairs, or</span></div><div>2) split each receive operation into one Irecv of known length 1 MPI_INT that gives the size of the next message, then a blocking MPI_Recv of this size. No busy loop needed by one extra (yet small) message.</div><div><br></div><div>Matthieu<br><div><br><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Jim Dinan" <james.dinan@gmail.com><br><b>À: </b>discuss@mpich.org<br><b>Envoyé: </b>Lundi 5 Août 2013 08:28:42<br><b>Objet: </b>Re: [mpich-discuss] Generalized request classes<br><br><div dir="ltr"><div>MPI Grequests do generally require external progress, usually polling or a thread. It would be nice to see if we can make progress on the MPIX Grequests proposal. There are several unresolved issues holding up this proposal. Off the top of my head: What progress must MPI provide for the MPIX Grequest? How does this affect performance of implementations that do messaging in hardware? What can one do from within the polling function (make MPI calls, allocate memory, etc)?</div>
<div><br></div><div>Your question about Iprobe is interesting... One could imagine doing an MPI_Waitany on several communications, including one to receive a message of unknown length. I think the only way to do this right now would be to poll using Iprobe and Testany.</div>
<div><br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 4, 2013 at 6:24 PM, Rajeev Thakur <span dir="ltr"><<a href="mailto:thakur@mcs.anl.gov" target="_blank">thakur@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">MPI_Iprobe does not do any communication itself. It doesn't do a receive, for example. So there is no need to call test/wait after an Iprobe, since there is nothing to complete. Hence no request object.<br>
<br>
Rajev<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Aug 4, 2013, at 12:05 PM, Matthieu Dorier wrote:<br>
<br>
> Hi,<br>
><br>
> Is there any hope that the currently non-standard generalized request interface (MPIX_Grequest_*) in mpich eventually becomes part of the standard (or something that looks like this API)?<br>
> I just spent two days hopelessly trying to develop something with the standard generalized requests, but gave up: this API is basically useless unless a thread is used to do the MPI_Grequest_complete.<br>
><br>
> For information, what I was trying to do was a custom version of MPI_Iprobe that takes an MPI_Request* parameter instead of a int* flag and an MPI_Status*, in order to be able to call MPI_{Wait,Test}{all,any,some} on requests generated by different types of non-blocking operations including MPI_Iprob. (btw, is there a reason why MPI_Iprob doesn't have this signature already? That would have make more sense, in my opinion).<br>
><br>
> Matthieu Dorier<br>
> PhD student at ENS Cachan Brittany and IRISA<br>
> <a href="http://people.irisa.fr/Matthieu.Dorier" target="_blank">http://people.irisa.fr/Matthieu.Dorier</a><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a><br>
> To manage subscription options or unsubscribe:<br>
> <a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
<br>
_______________________________________________<br>
discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>discuss mailing list discuss@mpich.org<br>To manage subscription options or unsubscribe:<br>https://lists.mpich.org/mailman/listinfo/discuss</blockquote><br></div></div></div></body></html>