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 <[email protected]>
SSG/DPD/PAT
Tel: +44 117 9071438
From:
[email protected] [mailto:[email protected]] On Behalf Of Richard Treumann
Sent: 31 January 2008 13:29
To:
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
Tele (845) 433-7846 Fax (845) 433-8363
[email protected]
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 [email protected]
> High Performance Computing Center (HLRS) .
phone ++49(0)711/685-65530
>
> Head of Dpmt Parallel Computing . . .
www.hlrs.de/people/rabenseifner
> Nobelstr. 19, D-70550
>
_______________________________________________
> mpi-21 mailing list
> [email protected]
> 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.