[mpi-21] Ballot 4 - Re: Request for interpretation

Thu Jan 31 14:55:15 CST 2008

Do we mean "implementation defined" instead of "undefined"?

On Thu, 31 Jan 2008 14:16:20 -0500
 Richard Treumann <treumann_at_[hidden]> 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_at_[hidden] 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 <james.h.cownie_at_[hidden]>
>> SSG/DPD/PAT
>> Tel: +44 117 9071438
>>
>> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]]
>> 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_at_[hidden] 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 <james.h.cownie_at_[hidden]>
>> > SSG/DPD/PAT
>> > Tel: +44 117 9071438
>> >
>> > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]]
>> > 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_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
>> > ---------------------------------------------------------------------
>> > 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_at_[hidden]
>> > 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_at_[hidden]
>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21

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)