What you are proposing amounts to a built-in version of "MPI_Cancel-after-timeout". So at the very least it has all of the downsides associated with cancel (esp. for send operations). It has the additional downside of forcing the MPI implementation to check all pending requests (that contain a timeout) for expiration. Other than my general dislike of message cancellation, I don't currently have a specific concern at this point, provided that the wording is sufficiently vague to permit timeout firing to be _very_ delayed. The multithreaded receive queue design that we sometimes use on Blue Gene would not permit this sort of cancellation in a timely fashion because it uses an additional, separate "fast post" queue in order to maximize message rate. Forcing timely timeouts would likely negate most of the performance benefit from such a design. Is there a good application use case for this functionality? Or is this just something amusing that is theoretically useful? -Dave On Mar 7, 2011, at 10:17 AM CST, Supalov, Alexander wrote:
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
_______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat