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

[Bronis R. de Supinski]

Rolf:

Re:
> This is a proposal for MPI 2.1, Ballot 4.
>
> I'm asking especially
>   Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud,
> the participants of the email-discussion in 1999, to review this proposal.

Linda has retired. I do remember this issue. Our position is
unchanged - your option 1, which you suggest adopting, is
clearly the right behavior to standardize.

A couple minor tweaks to the proposed wording below.

> This is a follow up to:
>   What info keys can be set?
>   in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.html
> with mail discussion in
>   http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/infoset/
> ___________________________________
> Background:
> The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38
>
>   "If a function does not recognize a key, it will ignore it,
>    unless otherwise specified."
>
> was interpreted in two different ways:
> 1. This sentence is only valid in the routines in other chapters
>    (e.g. processs creation and management, one-sided communication,
>    parallel file I/O) where infos may be used to specify portable
>    and implementation defined hints.
> 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET,
>    MPI_INFO_GET, and MPI_INFO_DUP.
> The following proposal ist based on Option 1.
> Option 2 is rejected due to the reason shown after the proposal.
> ___________________________________
>
> Proposal:
> MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read:
>    If a function does not recognize a key,
>    it will ignore it, unless otherwise specified.
> but should read:
>    If a function in another section of the MPI standard
>    does not recognize a key,
>    it will ignore it, unless otherwise specified.
>    The routines in this section.
>    The functions in this section must not ignore any (key,value) pair.

Something was garbled. Change to:

    If a function in any other section of the MPI standard
    does not recognize a key, it will ignore it, unless
    otherwise specified. The functions in this section
    must not ignore any (key,value) pair.

I'm not sure that "section" is well defined. Perhaps it would
be best to list the functions that cannot ignore unrecognized
pairs explicitly. Opinions?

> Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new
> paragraph:
>    Advice to implementors.
>    For optimization, an MPI implementation may already sort out
>    which (key,value) pair can be recognized for use in other chapters
>    (e.g., in processs creation and management, one-sided communication,
>    parallel file I/O) to guarantee a fast access to the appropriate
>    information when used in routines of those chapters.
>    For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY,
>    MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation
>    must still keep also all other (key,value) pairs that cannot be
>    recognized by that MPI implementation.
>    (End of advice to implementors.)

Tweaking:

    Advice to implementors.
    An MPI implementation may restrict (key,value) pairs that are valid
    for use in routines from other chapters (e.g., in processs creation
    and management, one-sided communication, or parallel file I/O) to
    guarantee fast access to the appropriate information. 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.)

"For optimization" and "fast access" are redundant.
Added rationalization for retaining the others pairs.
Various other grammar and spelling changes suggested.

Bronis

> ________________________________
> Rationale for this clarification:
>
>    The first of the two interpretation options mentioned in the
>    background information is the only valid interpretation
>    when we assume, that layered implementation of parts of
>    the MPI-2 standard should be possible.
>    This was a goal of the MPI-2 Forum and the MPI-2.0 specification.
> ___________________________________
>
> Comment:
> In the discussion (see the mails from 1999)
> one can clearly see, that an implementation of option 2 (done by IBM)
> cannot coexist with a layered implementation of MPI parallel
> file I/O, because MPI parallel file I/O routine need a different
> implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided)
> need the original INF implementation.
> Two different INFO implementations cannot coexist in the same MPI library.
>
> We could see the ouutcome of such problems with MPI_Wait & co.
> as long as a generalized request concept was not available.
> ROMIO had to define non-standard MPIO_Wait & co. routines.
> And they persist for a long time!
>
> Without the clarification above, we have the same problem with the
> INFO handling.
>
> 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
>