[Mpi3-bwcompat] MPI timer requests

Tue Mar 8 12:32:04 CST 2011

Thanks. It looks like Dave got me: implied cancellation is not what looks practical. Better keep timeouts orthogonal, as you originally proposed.

-----Original Message-----
From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Fab Tillier
Sent: Monday, March 07, 2011 6:26 PM
To: MPI-3 backwards compatability WG
Subject: Re: [Mpi3-bwcompat] MPI timer requests

Hi Alexander,

Your idea of post-conditioning a request wouldn't require any changes to existing APIs - I like it.  The pre-conditioning however would make the request parameter inout to all functions that currently return one, which would break backward compatibility (users would need to initialize all input requests to MPI_REQUEST_NULL if they didn't have a pre-conditioned request).

If you associate a timeout with individual requests, what happens to a request when it times out?  Does it complete in error?  Is it complete at all, or does the wait function simply return?

One of the reasons for having separate timer requests rather than adding a timeout to existing requests is that the timeout condition remains completely local and doesn't indicate anything about outstanding I/O request.  This leaves it up to the application to figure out how to handle the timeout.  If an error, a send request could be cancelled, for example.

Thanks,
-Fab

-----Original Message-----
From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Supalov, Alexander
Sent: Monday, March 07, 2011 4:05 AM

Hi,

The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there?

As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning":

MPI_Isend(..., &req);
MPI_Timer_set(MPI_Wtime() + 5, &req);
...
MPI_Wait(&req);

Or, for "preconditioning":

MPI_Timer_create(MPI_Wtime() + 5, &req); MPI_Isend(..., &req); ...
MPI_Wait(&req);

The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think?

Best regards.

Alexander

-----Original Message-----
From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell
Sent: Friday, March 04, 2011 10:21 PM
To: MPI-3 backwards compatability WG
Subject: Re: [Mpi3-bwcompat] MPI timer requests

I have mixed feelings about the idea.  When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions.

I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations.  I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work.

-Dave

On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote:

> All --
> 
> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting.  We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked.
> 
> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback?  We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum.
> 
>    
> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers
> 
> Thanks!
> 
> --
> Jeff Squyres
> jsquyres_at_[hidden]
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

_______________________________________________
Mpi3-bwcompat mailing list
Mpi3-bwcompat_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
--------------------------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

_______________________________________________
Mpi3-bwcompat mailing list
Mpi3-bwcompat_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

_______________________________________________
Mpi3-bwcompat mailing list
Mpi3-bwcompat_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
--------------------------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland 
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052