[Mpi-22] Empty members and MPI_TYPE_GET_CONTENTS

Richard Treumann treumann at [hidden]
Wed Dec 10 13:48:35 CST 2008

There has been a first vote on this issue. I was not present for the
discussion so I would like to present my argument for a different outcome
on the second vote. The first vote opted for the position that
MPI_TYPE_GET_CONTENTS should return information on empty type constructor
inputs, ones that had replication count or block lengths arguments of zero.
I do not think that is the best answer.  Here is the issue as stated in the

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.

The alternatives provided were:
The datatypes returned in array_of_datatypes are handles to datatype
objects that are equivalent to
the datatypes used in the original construction call, including any
zero-count datatypes that were
specified in the original datatype constructor.

 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 0 count or 0 blocklength are not considered significant)

Here are my arguments for the second option:

1) The phrasing now in MPI-2.1: p78:18-20 enumerates the relevant
"contents" of a datatype object and says none of these contents are
affected by a parameter that represents 0 bytes. If an input parameter does
not affect the "contents" it does not seem consistent to require that
MPI_TYPE_GET_CONTENTS report that input.  The function is not

2) The primary uses for MPI_TYPE_GET_ENVELOP and MPI_TYPE_GET_CONTENTS are
to provide a way for tools and opaque libraries to learn the data layout of
a datatype created elsewhere. Any input to a type constructor that did not
affect type signature, offsets, bounds or extent is irrelevant to this
purpose. If MPI_TYPE_GET_CONTENTS returns this irrelevant history then the
user of MPI_TYPE_GET_CONTENTS must have special case code to filter out
this chaff.

Note: there was a suggestion in the ticket that the the "user" who created
a datatype that includes 0 byte members ought to be willing to deal with
them when he calls MPI_TYPE_GET_CONTENTS - the problem with this logic is
that the user who created such a datatype is not the user who must filter
that does not control the entire application will need to filter the output
in case someone he cannot control produces datatypes with empty members. If
he does not filter out this chaff, he must test all his algorithms that use
the results of MPI_TYPE_GET_CONTENTS to ensure they tolerate empty members.

3) As long as MPI_TYPE_GET_ENVELOP only counts those components that became
part of the contents under MPI-2.1: p78:18-20, the effect is transparent
for datatypes that represent at least one byte.  A totally empty datatype
will return 0 for the envelope size and that ends the matter.  There is no
need to call MPI_TYPE_GET_CONTENTS. If MPI_TYPE_GET_ENVELOP counts empty
members then the user of MPI_TYPE_GET_CONTENTS will not know a datatype
represents 0 bytes unless he adds code to check each member size.

ee ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/2

Dick Treumann  -  MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20081210/eb417398/attachment.html>

More information about the Mpi-22 mailing list