An application that is really trying to do overlap of communication and computation is likely to post Isends and Irecvs before entering a computation step. If the computation step discovers the answer and another iteration is not needed then why require all the sends and receives to be done? The application already knows the data is useless.

A master/worker application may have an outstanding MPI_Irecv at each worker with tag 1 to pick up workload and an outstanding MPI_Irecv with tag 2 that is looking for the "all done" message. When the "all done" shows up, the workload MPI_Irecv needs to be completed before a disconnect can proceed. Why make the master send a null workload to each worker just to clear those obsolete MPI_Irecvs?

The standard has several points at which it states that all outstanding sends and receives must be complete. If an Isend or Irecv has been posted there are 2 ways to complete it: Make the matching Send or Recv happen or call MPI_Cancel. The pair of operations MPI_Cancel; MPI_Wait will always complete no matter what the other side does. As long as the application does not care whether the data is delivered, this is a clean way to satisfy the requirement that all outstanding sends and receives must be complete.

I have not been following the FT stuff but it seems like MPI_Cancel would be useful there. If I have posted an MPI_Irecv from task 9 and then learned task 9 is gone why wouldn't I want the option of doing an MPI_Cancel on the MPI_Irecv request? That seems cleaner than any other way of getting rid of the receive descriptor.


Dick Treumann - MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363


"Supalov, Alexander" ---01/13/2010 03:52:11 PM---Thanks. Do we know any active app that uses the JOIN still? If none, why the heck keep it afloat? I

From:	"Supalov, Alexander" <alexander.supalov@intel.com>
To:	"MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft@lists.mpi-forum.org>
Date:	01/13/2010 03:52 PM
Subject:	Re: [Mpi3-ft] Nonblocking Process Creation and Management
Sent by:	mpi3-ft-bounces@lists.mpi-forum.org

Why would JOIN be any less useful today than in the past? Why would you want to deprecate it? It is a trivial bootstrap for the simplest form of ACCEPT/CONNECT. It just hides the ACCEPT and CONNECT operations and lets the user handle the complexity of identifying the two end points any way he likes.

I never felt JOIN was needed very badly but it went in as a "what the heck" decision and I do not see that anything has changed.

Is it because IJOIN seems more difficult than IACCEPT and ICONNECT in some way?

When you say CANCEL should be deprecated, do you mean MPI_Cancel of an outstanding ISEND/IRECV request or something else?

Dick Treumann - MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363


"Supalov, Alexander" ---01/13/2010 02:53:18 PM---Thanks. I meant the JOIN per se as a way of establishing the communicator. Do we need that still? Wh

From:	"Supalov, Alexander" <alexander.supalov@intel.com>
To:	"MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft@lists.mpi-forum.org>
Date:	01/13/2010 02:53 PM
Subject:	Re: [Mpi3-ft] Nonblocking Process Creation and Management
Sent by:	mpi3-ft-bounces@lists.mpi-forum.org

---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
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 (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.