[mpi-21] Ballot 4 - Re: Request for interpretation
Richard Treumann
treumann at [hidden]
Thu Jan 31 07:28:54 CST 2008
Your wording works for me Rolf. -- Thanks
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
mpi-21-bounces_at_[hidden] wrote on 01/31/2008 05:25:46 AM:
> I try to summarize all 3 replies in one proposal:
>
> ___________________________________
>
> Proposal:
> MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read:
> If a function does not recognize a key,
> it will ignore it, unless otherwise specified.
> If an implementation recognizes a key but does not recognize
> the format of the corresponding value, the result is undefined.
> but should read:
> An implementation must support info objects as caches for arbitrary
> (key, value) pairs, regardless of whether it recognizes the pairs.
> Each MPI function which takes hints in the form of an MPI_Info must
> be prepared to ignore any key it does not recognize.
>
> Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new
> paragraph:
> Advice to implementors.
> Although in MPI functions that take hints in form of an MPI_Info
> (e.g., in process creation and management, one-sided communication,
> or parallel file I/O), an implementation must be prepared to ignore
> keys that it does not recognize, for the purpose of
MPI_INFO_GET_NKEYS,
> MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the
> implementation must retain all (key,value) pairs so that layered
> functionality can also use the Info object.
> (End of advice to implementors.)
> _____________________________
> Rationale for this clarification:
>
> The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET,
> MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs
> that are not recognized in routines in other chapters that
> take hints with info arguments.
> The proposed clarification is necessary when we assume, that
> layered implementation of parts of the MPI-2 standard should
> be possible and may use the MPI_Info objects for their needs.
> This was a goal of the MPI-2 Forum and the MPI-2.0 specification.
> ___________________________________
>
> Bronis, for me, your wording "an MPI implementation may restrict" was
> in conflict with the rest of the advice. I hope the formulation above
> is also okay. It is based on the new wording from you and Dick in first
> part of the proposal.
>
> Best regards
> Rolf
>
>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> _______________________________________________
> mpi-21 mailing list
> mpi-21_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-21/attachments/20080131/eb3f5ecd/attachment.html>
More information about the Mpi-21
mailing list