[mpich-discuss] Generalized request classes

[Matthieu Dorier]

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 
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. 

Matthieu 

----- Mail original -----

> De: "Jim Dinan" <james.dinan at gmail.com>
> À: discuss at mpich.org
> Envoyé: Lundi 5 Août 2013 08:28:42
> Objet: Re: [mpich-discuss] Generalized request classes

> 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)?

> 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.

> ~Jim.

> On Sun, Aug 4, 2013 at 6:24 PM, Rajeev Thakur < thakur at mcs.anl.gov >
> wrote:

> > 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.
> 

> > Rajev
> 

> > On Aug 4, 2013, at 12:05 PM, Matthieu Dorier wrote:
> 

> > > Hi,
> 
> > >
> 
> > > 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)?
> 
> > > 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.
> 
> > >
> 
> > > 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).
> 
> > >
> 
> > > Matthieu Dorier
> 
> > > PhD student at ENS Cachan Brittany and IRISA
> 
> > > http://people.irisa.fr/Matthieu.Dorier
> 

> > > _______________________________________________
> 
> > > discuss mailing list discuss at mpich.org
> 
> > > To manage subscription options or unsubscribe:
> 
> > > https://lists.mpich.org/mailman/listinfo/discuss
> 

> > _______________________________________________
> 
> > discuss mailing list discuss at mpich.org
> 
> > To manage subscription options or unsubscribe:
> 
> > https://lists.mpich.org/mailman/listinfo/discuss
> 

> _______________________________________________
> discuss mailing list discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130805/0b5f9f5b/attachment.html>