On Thu, 16 Jan 1997, Rajeev Thakur wrote:
> Date: Thu, 16 Jan 1997 17:53:44 -0600
> From: Rajeev Thakur <firstname.lastname@example.org>
> To: email@example.com
> Subject: Re: new GR proposal(s)
> > Date: Thu, 16 Jan 1997 15:10:28 -0800 (PST)
> > From: Linda Stanberry <firstname.lastname@example.org>
> > 2. Rajeev's proposal to make GRs nonpersistent means that I can't use
> > MPI_Start (without redefining it) since it is currently only defined for
> > persistent requests. This may be ok since there are implications for
> > hooks in MPI_TEST/WAIT already to support GRs, as well as implications
> > for the "progress engine" of MPI. But the details need to be hammered
> > out! (How does the Forum view adding semantics to existing routines?)
> Yes, one of the drawbacks of making GRs nonpersistent is that one
> cannot use GRs to implement any persistent operations defined in
> MPI-2, such as the new persistent collective operations in the
> collective chapter.
> That problem can be solved as follows:
> Allow both persistent and nonpersistent GRs and provide two functions:
> 1. MPI_Request_Init: The same as in Raja and Eric's proposal. This is
> to be used to create persistent GRs that must be
> started with MPI_Start and must be freed sometime
> with MPI_Request_free.
> 2. MPI_Irequest: This is the same as the new MPI_Request_Init I
> suggested in my previous mail that Raja suggested
> renaming to MPI_Irequest. It takes callback fns,
> extra_state and starts a new nonpersistent GR that is
> automatically freed by a successful MPI_Test/MPI_Wait.
> Does this make sense?
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: email@example.com; Try MPI!