From: Richard Treumann Date: January 31, 2008 3:41:09 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" Not quite; For example the standard offers:( ( { cb_buffer_size} (integer) {SAME}: " This hint specifies the total buffer space that can be used for collective buffering on each target node, usually a multiple of cb_block_size. The standard says a program is "erroneous" if the value is not the same at all callers. That is not exactly the same as the standard defining behavior for MPI_FILE_OPEN with a valid key and garbage value but pretty close. If MPI 3 adds new defined keys for new specific functions it may or may not want to go into defining behavior for some kinds of bad input. 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 03:55:15 PM: > 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 _______________________________________________ mpi-21 mailing list mpi-21@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21