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

Thu Jan 31 09:10:39 CST 2008

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" <james.h.cownie_at_[hidden]> 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 <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.
>
>
>
> 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
>