From: "Bronis R. de Supinski" Date: January 31, 2008 9:10:39 AM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation Reply-To: "Bronis R. de Supinski" for discussion of MPI 2.1" Rolf: Re: > Sorry, that was my fault. > Here again the full proposal including your sentence > (and nothing else changed): Still fine with me although there is aminor grammar issue that needs to be fixed. The "which" should be "that" - the correct difference between the two is to use "that" for "required" clauses (i.e., clauses withouth which the sentence no longer makes sense, essentially) and "which" preceded by a comma for others (typically apository clauses). See below. Bronis > ___________________________________ > > 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 Change the above to: Each MPI function that takes hints in the form of an MPI_Info must > be prepared to ignore any key it does not recognize. > However if a function recognizes a key but not the associated > value, > then the behavior is undefined. > > 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. > ___________________________________ > > Best regards > Rolf > > On Thu, 31 Jan 2008 13:43:04 -0000 > "Cownie, James H" wrote:>> However, you have apparently lost the liberty to have undefined >> behavior >> which was there in the previous version. >> >> >> >> Maybe you should keep that, something like >> >> An implementation must support info objects as caches for arbitrary >> (key, value) pairs, regardless of whether it recognizes the keys. >> Each >> MPI function which takes hints in the form of an MPI_Info must >> be prepared to ignore any key it does not recognize. However if a >> function recognizes a key but not the associated value, then the >> behavior is undefined. >> >> (Modifications in italics) >> >> -- Jim >> >> James Cownie >> SSG/DPD/PAT >> Tel: +44 117 9071438 >> >> ________________________________ >> >> From: mpi-21-bounces@XXXXXXXXXXX [mailto:mpi-21- >> bounces@XXXXXXXXXXXX On >> Behalf Of Richard Treumann >> Sent: 31 January 2008 13:29 >> To: Mailing list for discussion of MPI 2.1 >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation >> >> >> >> 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@XXXXXXXXXXX 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@XXXXXXX >>> 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@XXXXXXXXXXX >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> --------------------------------------------------------------------- >> Intel Corporation (UK) Limited >> Registered No. 1134945 (England) >> Registered Office: Pipers Way, Swindon SN3 1RJ >> VAT No: 860 2173 47 >> >> 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. > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXX > 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@XXXXXXXXXXX > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > _______________________________________________ mpi-21 mailing list mpi-21@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21