FYI -- this contentious ticket has been withdrawn. The reviewers and myself all missed a statement immediately preceding the language neutral bindings of MPI_TYPE_GET_CONTENTS that says: The actual arguments used in the creation call for a datatype can be obtained from the call: Hence, the current text is perfectly clear on what the behavior should be. Begin forwarded message:
From: "MPI Forum" <mpi-22_at_[hidden]> Date: February 10, 2009 3:43:48 PM PST Subject: Re: [MPI Forum] #2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1
#2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1 -------------------------------- +------------------------------------------- Reporter: jsquyres | Owner: jsquyres Type: Text (only) changes | Status: closed Priority: Waiting for reviews | Milestone: 2009/02/09 San Jose Version: MPI 2.2 | Resolution: Withdrawn Keywords: | -------------------------------- +------------------------------------------- Changes (by jsquyres):
* status: assigned => closed * resolution: => Withdrawn
Old description:
== Description ==
Sep 8 2008 Straw Vote
|| return 0|| don't return 0 || Abstain || || 17 || 1 || 9 ||
MPI-2.1 introduced an ambiguity in the interpretation of what MPI_TYPE_GET_CONTENTS is supposed to return. Specifically: MPI-2.1 introduced that user-defined datatypes could be created with zero counts for datatypes. The ambiguity originates from two sections of text:
* MPI-2.1: p78:18-20 Most datatype constructors have replication count or block length arguments. Allowed values are nonnegative integers. If the value is zero, no elements are generated in the type map and there is no effect on datatype bounds or extent. * MPI-2.1: p107:47-48 The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to the datatypes used in the original construction call.
If datatype constructors accept 0-count datatype arguments that are supposed to have "no elements are generated in the type map" and "no effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS return those 0-count datatypes in array_of_datatypes? After all, MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to contain handles to datatype objects that are equivalent to the datatypes used in the original construction call (which used 0-count datatypes).
A similar problem exists with MPI_TYPE_GET_ENVELOPE; does num_datatypes contain a count of all the zero-count datatypes specified in the constructor?
== History ==
Ambiguity was accidentally introduced in MPI-2.1 (verified in July 2008 Forum meeting).
== Proposed Solution ==
Change MPI-2.1 p107:47-48 from:
The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to the datatypes used in the original construction call.
to
The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to the significant datatypes used in the original construction call (datatypes with zero count or zero blocklength are not considered significant).
== Impact on Implementations ==
Implementations that return zero-count or zero-blocklength datatypes will need to be updated to not return them.
== Impact on Applications / Users ==
Applications will need to recognize that zero-count/zero-blocklength datatypes will not be returned from MPI_TYPE_CONTENTS. This is not expected to be a burden because the the intended consumers of MPI_TYPE_CONTENTS are looking for the "significant" datatypes (vs. looking for insignificant datatypes that will just be discarded).
== Alternative Solutions ==
* Change it so that MPI_TYPE_CONTENTS specifically returns zero- count/ zero-blocklength datatypes. This does not seem useful to the expected consumers of MPI_TYPE_CONTENTS. * Allow MPI implementations to either return the zero-count datatypes or not. From the user perspective, this is the same as requiring MPI implementations to return the zero-count datatypes because the application will need to check for zero-count datatypes in array_of_datatypes.
== Entry for the Change Log ==
Section 4.1.13 on page 104. Remove ambiguity regarding zero-count datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS.
New description:
== Description ==
Sep 8 2008 Straw Vote
|| return 0|| don't return 0 || Abstain || || 17 || 1 || 9 ||
MPI-2.1 introduced an ambiguity in the interpretation of what MPI_TYPE_GET_CONTENTS is supposed to return. Specifically: MPI-2.1 introduced that user-defined datatypes could be created with zero counts for datatypes. The ambiguity originates from two sections of text:
* MPI-2.1: p78:18-20 Most datatype constructors have replication count or block length arguments. Allowed values are nonnegative integers. If the value is zero, no elements are generated in the type map and there is no effect on datatype bounds or extent. * MPI-2.1: p107:47-48 The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to the datatypes used in the original construction call.
If datatype constructors accept 0-count datatype arguments that are supposed to have "no elements are generated in the type map" and "no effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS return those 0-count datatypes in array_of_datatypes? After all, MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to contain handles to datatype objects that are equivalent to the datatypes used in the original construction call (which used 0-count datatypes).
A similar problem exists with MPI_TYPE_GET_ENVELOPE; does num_datatypes contain a count of all the zero-count datatypes specified in the constructor?
== History ==
Ambiguity was accidentally introduced in MPI-2.1 (verified in July 2008 Forum meeting).
== Proposed Solution ==
Change MPI-2.1 p107:47-48 from:
The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to the datatypes used in the original construction call.
to
The datatypes returned in array_of_datatypes are handles to the same
handles to datatype objects that are identical to the datatypes used in the original construction call, including any zero-count datatypes that were specified in the original datatype constructor.
== Impact on Implementations ==
Implementations may need to be updated to save a copy of the datatypes passed to datatype constructor functions.
== Impact on Applications / Users ==
Applications will need to handle zero-count datatypes in what they get back from MPI_TYPE_CONTENTS. This is not expected to be a burden because the user created the datatype with a zero-count datatype anyway.
== Alternative Solutions ==
* Change it so that MPI_TYPE_CONTENTS specifically excludes zero- count datatypes. This does not seem to be consistent. * Allow MPI implementations to either return the zero-count datatypes or not. From the user perspective, this is the same as requiring MPI implementations to return the zero-count datatypes because the application will need to check for zero-count datatypes in array_of_datatypes.
== Entry for the Change Log ==
Section 4.1.13 on page 104. Remove ambiguity regarding zero-count datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS.
--
Comment:
It turns out that all of us missed the following statement MPI-2.1 p107:1-2:
The actual arguments used in the creation call for a datatype can be obtained from the call:
(followed by the language neutral binding for MPI_TYPE_GET_CONTENTS)
Hence, I withdraw this ticket -- the current text is perfectly clear on exactly what the behavior should be (sorry Dick!).
-- Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/2#comment:26
MPI Forum <https://svn.mpi-forum.org/> MPI Forum
-- Jeff Squyres Cisco Systems