From: "Rolf Rabenseifner" Date: January 31, 2008 2:55:15 PM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation Reply-To: "Mailing list for discussion of MPI 2.1" Do we mean "implementation defined" instead of "undefined"? On Thu, 31 Jan 2008 14:16:20 -0500 Richard Treumann wrote:> Jim > > The sense I get from the phrase "the behavior is undefined" is that > defining the behavior is beyond the scope of the standard. > > The MPI standard does have some predefined keys and requires an > implementation that supports any predefined key to support it as > described > by the standard. That can lead to one place in the standard saying > "the > behavior is undefined" and another saying "here is the definition > of the > behavior". > > Maybe I am reading more than others into the phrase "the behavior is > undefined" but it does have this strong implication in my mind. > > How is this ? > > An implementation must support info objects as caches for arbitrary > key, value) pairs, regardless of whether it recognizes the key. > Each function that takes hints in the form of an MPI_Info must > be prepared to ignore any key it does not recognize. This description > of info objects does not attempt to define how a particular function > should react if it recognizes a key but not the associated value. > > note: > I also changed MPI function to simply function because with this > free form > approach to the info object, it seems to me a third party library > that is > intended to work as part of an MPI program may want to use MPI_Info > objects > too. If someone authors a parallel math library and wants the > initialization routine to look like: > init_pmath( MPI_Info info) > why not? They should understand that init_pmath must ignore keys > it does > not recognize even if i is not an MPI_ routine. > > > Dick > > 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 09:39:52 AM: > >> As you are saying, there are two different classes of errors here. >> >> 1) Keys which are not understood and need to be ignored by functions >> which don't grok them (``JIMS_SECRET_TAG'',''99'') >> 2) Keys which are understood by a function, but with a value which >> is not (``buffer_size'', ``Hello'') >> >> I think allowing the second type to have undefined behavior is the >> right thing to do, since it's the most general. >> If your implementation wants to define the behavior of some out-of- >> range values, that's fine and doesn't make you non-conforming, it >> just means you defined the previously undefined behavior for some >> set of values. >> >> Having that undefined-ness explicit here (in one central place) >> seems to make sense (if only because it may be omitted in one of the >> other places where it should appear). >> >> My addition does not alter the existing change which guarantees case >> 1, it's only concerned with case 2. >> -- Jim >> >> James Cownie >> SSG/DPD/PAT >> Tel: +44 117 9071438 >> >> From: mpi-21-bounces@XXXXXXXXXXX [mailto:mpi-21-bounc >> On Behalf Of Richard Treumann >> Sent: 31 January 2008 14:20 >> To: Mailing list for discussion of MPI 2.1 >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation >> >> Jim - >> >> I was taking the view that the description of what to do for a >> recognized key but dubious value belongs to the function that >> recognizes the specific key. For example if MPI_File_open accepts a >> "buffer_size" hint with range "32K" to "16M" we may want to define >> the behavior of hints that are out of range. >> >> Once we say an info can have arbitrary keys we need to state that >> every info consumer must be prepared to ignore keys it does not >> recognize because we have made unrecognizable keys legitimate. >> >> Dick >> 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 08:43:04 AM: >> >>> 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-bounc >>> 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. >>> _______________________________________________ >>> 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. >> _______________________________________________ >> mpi-21 mailing list >> mpi-21@XXXXXXXXXXX >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 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