[Mpi3-bwcompat] MPI timer requests

[Supalov, Alexander]

Can you give an example of the impact you're indicating? On an afterthought there may be an atomicity issue with the postconditioning. Shouldn't be a big problem though: if the message has matched, attaching a timeout to it will effectively be a no-op. Is your concern going in a comparable direction? Like, what happens if the message is matched just before the timeout fires, or vice versa?

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

What would be the impact of such a proposal on message matching and ordering semantics?  I suspect this would make developing an efficient receive queue implementation even more difficult than it already is.

-Dave

On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote:

> 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