<html><body>
<p>Not quite; For example the standard offers:<br>
<br>
<b><font size="4">{</font></b><font size="4"> cb_buffer_size} (integer) {SAME}:</font>
<ul>
<ul><font size="4">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.</font><br>
</ul>
</ul>
The standard says a program is "<font size="4">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.</font><br>
<br>
<font size="4"> Dick </font><br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-21-bounces@cs.uiuc.edu wrote on 01/31/2008 03:55:15 PM:<br>
<br>
> Do we mean "implementation defined" instead of "undefined"?<br>
> <br>
> On Thu, 31 Jan 2008 14:16:20 -0500<br>
> Richard Treumann <treumann@us.ibm.com> wrote:<br>
> >Jim<br>
> ><br>
> >The sense I get from the phrase "the behavior is undefined" is that<br>
> >defining the behavior is beyond the scope of the standard.<br>
> ><br>
> >The MPI standard does have some predefined keys and requires an<br>
> >implementation that supports any predefined key to support it as described<br>
> >by the standard. That can lead to one place in the standard saying "the<br>
> >behavior is undefined" and another saying "here is the definition of the<br>
> >behavior".<br>
> ><br>
> >Maybe I am reading more than others into the phrase "the behavior is<br>
> >undefined" but it does have this strong implication in my mind.<br>
> ><br>
> >How is this ?<br>
> ><br>
> >An implementation must support info objects as caches for arbitrary<br>
> >key, value) pairs, regardless of whether it recognizes the key.<br>
> >Each function that takes hints in the form of an MPI_Info must<br>
> >be prepared to ignore any key it does not recognize. This description<br>
> >of info objects does not attempt to define how a particular function<br>
> >should react if it recognizes a key but not the associated value.<br>
> ><br>
> >note:<br>
> >I also changed MPI function to simply function because with this free form<br>
> >approach to the info object, it seems to me a third party library that is<br>
> >intended to work as part of an MPI program may want to use MPI_Info objects<br>
> >too. If someone authors a parallel math library and wants the<br>
> >initialization routine to look like:<br>
> > init_pmath( MPI_Info info)<br>
> >why not? They should understand that init_pmath must ignore keys it does<br>
> >not recognize even if i is not an MPI_ routine.<br>
> ><br>
> ><br>
> > Dick<br>
> ><br>
> >Dick Treumann - MPI Team/TCEM<br>
> >IBM Systems & Technology Group<br>
> >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
> >Tele (845) 433-7846 Fax (845) 433-8363<br>
> ><br>
> ><br>
> >mpi-21-bounces@cs.uiuc.edu wrote on 01/31/2008 09:39:52 AM:<br>
> ><br>
> >> As you are saying, there are two different classes of errors here.<br>
> >><br>
> >> 1) Keys which are not understood and need to be ignored by functions<br>
> >> which don’t grok them (“JIMS_SECRET_TAG”,”99”)<br>
> >> 2) Keys which are understood by a function, but with a value which<br>
> >> is not (“buffer_size”, “Hello”)<br>
> >><br>
> >> I think allowing the second type to have undefined behavior is the<br>
> >> right thing to do, since it’s the most general.<br>
> >> If your implementation wants to define the behavior of some out-of-<br>
> >> range values, that’s fine and doesn’t make you non-conforming, it<br>
> >> just means you defined the previously undefined behavior for some<br>
> >> set of values.<br>
> >><br>
> >> Having that undefined-ness explicit here (in one central place)<br>
> >> seems to make sense (if only because it may be omitted in one of the<br>
> >> other places where it should appear).<br>
> >><br>
> >> My addition does not alter the existing change which guarantees case<br>
> >> 1, it’s only concerned with case 2.<br>
> >> -- Jim<br>
> >><br>
> >> James Cownie <james.h.cownie@intel.com><br>
> >> SSG/DPD/PAT<br>
> >> Tel: +44 117 9071438<br>
> >><br>
> >> From: mpi-21-bounces@cs.uiuc.edu [<a href="mailto:mpi-21-bounces@cs.uiuc.edu">mailto:mpi-21-bounces@cs.uiuc.edu</a>]<br>
> >> On Behalf Of Richard Treumann<br>
> >> Sent: 31 January 2008 14:20<br>
> >> To: Mailing list for discussion of MPI 2.1<br>
> >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation<br>
> >><br>
> >> Jim -<br>
> >><br>
> >> I was taking the view that the description of what to do for a<br>
> >> recognized key but dubious value belongs to the function that<br>
> >> recognizes the specific key. For example if MPI_File_open accepts a<br>
> >> "buffer_size" hint with range "32K" to "16M" we may want to define<br>
> >> the behavior of hints that are out of range.<br>
> >><br>
> >> Once we say an info can have arbitrary keys we need to state that<br>
> >> every info consumer must be prepared to ignore keys it does not<br>
> >> recognize because we have made unrecognizable keys legitimate.<br>
> >><br>
> >> Dick<br>
> >> Dick Treumann - MPI Team/TCEM<br>
> >> IBM Systems & Technology Group<br>
> >> Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
> >> Tele (845) 433-7846 Fax (845) 433-8363<br>
> >><br>
> >><br>
> >> mpi-21-bounces@cs.uiuc.edu wrote on 01/31/2008 08:43:04 AM:<br>
> >><br>
> >> > However, you have apparently lost the liberty to have undefined<br>
> >> > behavior which was there in the previous version.<br>
> >> ><br>
> >> > Maybe you should keep that, something like<br>
> >> > An implementation must support info objects as caches for arbitrary<br>
> >> > (key, value) pairs, regardless of whether it recognizes the keys.<br>
> >> > Each MPI function which takes hints in the form of an MPI_Info must<br>
> >> > be prepared to ignore any key it does not recognize. However if a<br>
> >> > function recognizes a key but not the associated value, then the<br>
> >> > behavior is undefined.<br>
> >> > (Modifications in italics)<br>
> >> > -- Jim<br>
> >> ><br>
> >> > James Cownie <james.h.cownie@intel.com><br>
> >> > SSG/DPD/PAT<br>
> >> > Tel: +44 117 9071438<br>
> >> ><br>
> >> > From: mpi-21-bounces@cs.uiuc.edu [<a href="mailto:mpi-21-bounces@cs.uiuc.edu">mailto:mpi-21-bounces@cs.uiuc.edu</a>]<br>
> >> > On Behalf Of Richard Treumann<br>
> >> > Sent: 31 January 2008 13:29<br>
> >> > To: Mailing list for discussion of MPI 2.1<br>
> >> > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation<br>
> >> ><br>
> >> > Your wording works for me Rolf. -- Thanks<br>
> >> ><br>
> >> ><br>
> >> > Dick Treumann - MPI Team/TCEM<br>
> >> > IBM Systems & Technology Group<br>
> >> > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
> >> > Tele (845) 433-7846 Fax (845) 433-8363<br>
> >> ><br>
> >> ><br>
> >> > mpi-21-bounces@cs.uiuc.edu wrote on 01/31/2008 05:25:46 AM:<br>
> >> ><br>
> >> > > I try to summarize all 3 replies in one proposal:<br>
> >> > ><br>
> >> > > ___________________________________<br>
> >> > ><br>
> >> > > Proposal:<br>
> >> > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read:<br>
> >> > > If a function does not recognize a key,<br>
> >> > > it will ignore it, unless otherwise specified.<br>
> >> > > If an implementation recognizes a key but does not recognize<br>
> >> > > the format of the corresponding value, the result is undefined.<br>
> >> > > but should read:<br>
> >> > > An implementation must support info objects as caches for<br>
> >arbitrary<br>
> >> > > (key, value) pairs, regardless of whether it recognizes the pairs.<br>
> >> > > Each MPI function which takes hints in the form of an MPI_Info<br>
> >must<br>
> >> > > be prepared to ignore any key it does not recognize.<br>
> >> > ><br>
> >> > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new<br>
> >> > > paragraph:<br>
> >> > > Advice to implementors.<br>
> >> > > Although in MPI functions that take hints in form of an MPI_Info<br>
> >> > > (e.g., in process creation and management, one-sided<br>
> >communication,<br>
> >> > > or parallel file I/O), an implementation must be prepared to<br>
> >ignore<br>
> >> > > keys that it does not recognize, for the purpose of<br>
> >> MPI_INFO_GET_NKEYS,<br>
> >> > > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the<br>
> >> > > implementation must retain all (key,value) pairs so that layered<br>
> >> > > functionality can also use the Info object.<br>
> >> > > (End of advice to implementors.)<br>
> >> > > _____________________________<br>
> >> > > Rationale for this clarification:<br>
> >> > ><br>
> >> > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET,<br>
> >> > > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs<br>
> >> > > that are not recognized in routines in other chapters that<br>
> >> > > take hints with info arguments.<br>
> >> > > The proposed clarification is necessary when we assume, that<br>
> >> > > layered implementation of parts of the MPI-2 standard should<br>
> >> > > be possible and may use the MPI_Info objects for their needs.<br>
> >> > > This was a goal of the MPI-2 Forum and the MPI-2.0 specification.<br>
> >> > > ___________________________________<br>
> >> > ><br>
> >> > > Bronis, for me, your wording "an MPI implementation may restrict" was<br>
> >> > > in conflict with the rest of the advice. I hope the formulation above<br>
> >> > > is also okay. It is based on the new wording from you and Dick in<br>
> >first<br>
> >> > > part of the proposal.<br>
> >> > ><br>
> >> > > Best regards<br>
> >> > > Rolf<br>
> >> > ><br>
> >> > ><br>
> >> > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de<br>
> >> > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<br>
> >> > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<br>
> >> > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<br>
> >> > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)<br>
> >> > > _______________________________________________<br>
> >> > > mpi-21 mailing list<br>
> >> > > mpi-21@cs.uiuc.edu<br>
> >> > > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a><br>
> >> > ---------------------------------------------------------------------<br>
> >> > Intel Corporation (UK) Limited<br>
> >> > Registered No. 1134945 (England)<br>
> >> > Registered Office: Pipers Way, Swindon SN3 1RJ<br>
> >> > VAT No: 860 2173 47<br>
> >> ><br>
> >> > This e-mail and any attachments may contain confidential material for<br>
> >> > the sole use of the intended recipient(s). Any review or distribution<br>
> >> > by others is strictly prohibited. If you are not the intended<br>
> >> > recipient, please contact the sender and delete all copies.<br>
> >> > _______________________________________________<br>
> >> > mpi-21 mailing list<br>
> >> > mpi-21@cs.uiuc.edu<br>
> >> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a><br>
> >> ---------------------------------------------------------------------<br>
> >> Intel Corporation (UK) Limited<br>
> >> Registered No. 1134945 (England)<br>
> >> Registered Office: Pipers Way, Swindon SN3 1RJ<br>
> >> VAT No: 860 2173 47<br>
> >><br>
> >> This e-mail and any attachments may contain confidential material for<br>
> >> the sole use of the intended recipient(s). Any review or distribution<br>
> >> by others is strictly prohibited. If you are not the intended<br>
> >> recipient, please contact the sender and delete all copies.<br>
> >> _______________________________________________<br>
> >> mpi-21 mailing list<br>
> >> mpi-21@cs.uiuc.edu<br>
> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a><br>
> <br>
> <br>
> <br>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de<br>
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<br>
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<br>
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<br>
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)<br>
> _______________________________________________<br>
> mpi-21 mailing list<br>
> mpi-21@cs.uiuc.edu<br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a><br>
</tt></body></html>