If this is so, I suggest that any time any blocking collective is called
over a group G, then the MPI system may progress non-blocking
collective operations over G (and possibly all proper subsets, tbd).
I think we were expecting progress in the non-blocking collectives in the
same symmetry [per Marc] we would get from Isend or Irecv type operations.
Weakening the semantics certainly makes the implementations feasible, but
I expect that it also diminishes usefulness, as it is asserted that
overlapping the collective operation with other work is what is wanted.
-Tony
On Thu, 12 Dec 1996, Rolf Rabenseifner wrote:
> Date: Thu, 12 Dec 1996 17:19:11 +0100 (MEZ)
> From: Rolf Rabenseifner <Rabenseifner@RUS.Uni-Stuttgart.DE>
> To: mpi-coll@mcs.anl.gov
> Subject: Non-Blocking Collective in MPI-2
>
> Ammendment for Non-Blocking Collective Communication
>
> I suggest the following text:
>
> All persistent requests for collective operations can be started
> without blocking with MPI_START.
> The non-blocking collective operation can be completed by
> a call to MPI_TEST, MPI_TESTANY, MPI_TESTSOME, MPI_TESTALL
> or MPI_WAIT and the application must complete it with MPI_WAIT
> if the MPI implementation does not complete it with the test
> routines, see semantics and progress rule below.
> MPI_WAITANY, MPI_WAITSOME and MPI_WAITALL are not allowed
> with this request.
>
> Semantics of non-blocking collective operations and progress rule
>
> With MPI_START the operation is started, but each MPI
> implementation can choose whether the collective operation is
> done in the background when all involved MPI processes have
> started the operation or whether the operation is delayed until
> all involved processes have issued a MPI_WAIT.
> Using MPI_TEST the application must guarantee that after
> a finit number of negative tests the MPI_WAIT routine is
> called to guarantee that the non-blocking collective operation
> can be completed in the case of the second implementation choice.
>
> I think this proposal fulfills all the requirements discussed
> at the last forum:
>
> - it allows non-blocking implementation (on message-based systems)
> - it allows blocking implementation (on syst. with hardware support)
> - it gives the user a hint that he/she should not expect that it
> is implemented in the background
> - it is compatible to MPI 1.1 because MPI 1.1 defines in
> 3.7.4 "Semantics of Nonblocking Communications" only
> "Progress" rules for nonblocking receive and nonblocking send,
> but no general rule for nonblocking communication at all.
> - it gives all the users want -- I hope so.
>
> Is this a good idea?
> Does it solve all problems mentioned last meeting?
>
> Rolf
>
> Rolf Rabenseifner (Computer Center )
> Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
> Allmandring 30 Phone: ++49 711 6855530
> D-70550 Stuttgart 80 FAX: ++49 711 6787626
> Germany rabenseifner@rus.uni-stuttgart.de
>
Anthony Skjellum, PhD, Associate Professor of Computer Science;
Mississippi State University, Department of Computer Science & NSF ERC
Butler, Rm 300, PO Box 9637, Corner of Perry&Barr, Mississippi State,MS 39762
(601)325-8435 FAX: (601)325-8997; http://www.erc.msstate.edu/~tony;
"Persistence is fertile." ; e-mail: tony@cs.msstate.edu; Try MPI!