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

Rolf Rabenseifner rabenseifner at [hidden]
Thu Jan 31 08:21:18 CST 2008



Sorry, that was my fault.
Here again the full proposal including your sentence 
(and nothing else changed):

___________________________________

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



More information about the Mpi-21 mailing list