[mpi-21] Ballot 4 - Re: Request for interpretation
Cownie, James H
james.h.cownie at [hidden]
Fri Feb 1 04:47:51 CST 2008
I'm happy with Dick's statement, and I think we want "undefined" (as he
has) rather than "implementation defined".
If I recall correctly
undefined == any behavior is possible and there's no need to
document that behavior.
implementation defined == any behavior is possible, but the
implementation should document what it will do.
So they have the same property that the code is non-conforming and can
behave in any way, but "implementation defined" requires more work from
the library implementer's documentation department.
In this case defining the behavior may not be trivial, since there can
be many functions involved and an arbitrarily large set of possible
erroneous inputs. So it's reasonable, taking Dick's example,
MPI_File_open accepts a "buffer_size" hint with range "32K" to "16M"
we
may want to define the behavior of hints that are out of range.
to say "if the buffer_size is > 16M it is treated as 16M", but that
doesn't address what happens if the "buffer_size" is "monkey".
Neither "undefined" nor "implementation defined" prevent implementations
from defining the behavior, rather they both warn users that what
they're doing is non-portable, and the standard doesn't say what will
happen...
-- Jim
James Cownie <james.h.cownie_at_[hidden]>
SSG/DPD/PAT
Tel: +44 117 9071438
> -----Original Message-----
> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]]
On
> Behalf Of Rolf Rabenseifner
> Sent: 31 January 2008 20:55
> To: Mailing list for discussion of MPI 2.1
> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation
>
> Do we mean "implementation defined" instead of "undefined"?
>
> On Thu, 31 Jan 2008 14:16:20 -0500
> Richard Treumann <treumann_at_[hidden]> wrote:
> >Jim
> >
> >The sense I get from the phrase "the behavior is undefined" is that
> >defining the behavior is beyond the scope of the standard.
> >
> >The MPI standard does have some predefined keys and requires an
> >implementation that supports any predefined key to support it as
> described
> >by the standard. That can lead to one place in the standard saying
"the
> >behavior is undefined" and another saying "here is the definition of
the
> >behavior".
> >
> >Maybe I am reading more than others into the phrase "the behavior is
> >undefined" but it does have this strong implication in my mind.
> >
> >How is this ?
> >
> >An implementation must support info objects as caches for arbitrary
> >key, value) pairs, regardless of whether it recognizes the key.
> >Each function that takes hints in the form of an MPI_Info must
> >be prepared to ignore any key it does not recognize. This description
> >of info objects does not attempt to define how a particular function
> >should react if it recognizes a key but not the associated value.
> >
> >note:
> >I also changed MPI function to simply function because with this free
> form
> >approach to the info object, it seems to me a third party library
that is
> >intended to work as part of an MPI program may want to use MPI_Info
> objects
> >too. If someone authors a parallel math library and wants the
> >initialization routine to look like:
> > init_pmath( MPI_Info info)
> >why not? They should understand that init_pmath must ignore keys it
does
> >not recognize even if i is not an MPI_ routine.
> >
> >
> > Dick
> >
> >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 09:39:52 AM:
> >
> >> As you are saying, there are two different classes of errors here.
> >>
> >> 1) Keys which are not understood and need to be ignored by
functions
> >> which don't grok them ("JIMS_SECRET_TAG","99")
> >> 2) Keys which are understood by a function, but with a value which
> >> is not ("buffer_size", "Hello")
> >>
> >> I think allowing the second type to have undefined behavior is the
> >> right thing to do, since it's the most general.
> >> If your implementation wants to define the behavior of some out-of-
> >> range values, that's fine and doesn't make you non-conforming, it
> >> just means you defined the previously undefined behavior for some
> >> set of values.
> >>
> >> Having that undefined-ness explicit here (in one central place)
> >> seems to make sense (if only because it may be omitted in one of
the
> >> other places where it should appear).
> >>
> >> My addition does not alter the existing change which guarantees
case
> >> 1, it's only concerned with case 2.
> >> -- 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 14:20
> >> To: Mailing list for discussion of MPI 2.1
> >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation
> >>
> >> Jim -
> >>
> >> I was taking the view that the description of what to do for a
> >> recognized key but dubious value belongs to the function that
> >> recognizes the specific key. For example if MPI_File_open accepts a
> >> "buffer_size" hint with range "32K" to "16M" we may want to define
> >> the behavior of hints that are out of range.
> >>
> >> Once we say an info can have arbitrary keys we need to state that
> >> every info consumer must be prepared to ignore keys it does not
> >> recognize because we have made unrecognizable keys legitimate.
> >>
> >> Dick
> >> 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 08:43:04 AM:
> >>
> >> > 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.
> >> > _______________________________________________
> >> > 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.
> >> _______________________________________________
> >> mpi-21 mailing list
> >> mpi-21_at_[hidden]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
>
>
>
> 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.
More information about the Mpi-21
mailing list