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

[Rolf Rabenseifner]

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.

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. 

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.)
________________________________
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)