From: Dries Kimpe Date: March 17, 2007 12:57:03 PM CDT To: mpi-comments@XXXXXXXXXXXXX Cc: Dries.Kimpe@XXXXXXXXX Subject: MPI_File_get_view ambiguity There seems to be some ambiguity in the description of MPI_File_get_view: > From the standard: MPI_FILE_GET_VIEW returns the process's view of the data in the file. The current value of the displacement is returned in disp. The etype and filetype are new datatypes with typemaps equal to the typemaps of the current etype and filetype, respectively. The data representation is returned in datarep. The user is responsible for ensuring that datarep is large enough to hold the returned data representation string. The length of a data representation string is limited to the value of MPI_MAX_DATAREP_STRING. In addition, if a portable datatype was used to set the current view, then the corresponding datatype returned by MPI_FILE_GET_VIEW is also a portable datatype. If etype or filetype are derived datatypes, the user is responsible for freeing them. The etype and filetype returned are both in a committed state. Note: - "the etype and filetype ARE NEW DATATYPES with typemaps equal to the typemaps of the current etype and filetype" - "IF etype or filetype are DERIVED datatypes, THE USER IS RESPONSIBLE FOR FREEING THEM" Question: - Is a new datatype with a typemap equal to the typemap of a named datatype a derived datatype? If so, the user is always responsible for freeing the types return by MPI_File_get_view.Currently, mpich returns the actual datatype if the datatype is a named datatype. Remarks about this behavior: * The user has to use the MPI_Type_get_envelope function to determine if the type must be freed or not (since it is an error to attempt to free a predefined object/handle) * As far as I know, this makes MPI_File_get_view the only MPI function that returns a predefined datatype and requires additional checking to see if it is safe to free the datatype. The other MPI get functions (such as MPI_File_get_info, MPI_File_get_group) always return a new object. Exceptions: - MPI_Comm_get_parent: states that freeing the object could lead to a dangling reference - MPI_Type_get_contents: states that, only for predefined types, the type itself and not a copy is returned and that the user should not attempt to free the returned type in this case. For derived types, the function does returns a copy. In this function this is understandable since it is created to allow investigation of a given datatype; Returning a copy of a predefined type would make it impossible to determine the real fundamental building block(s) of a derived type. * For the errhandler functions, there was an errata stating that the free function should be called, because this is the expected behavior: (see errata & manual page in mpich for MPI_Errhandler_get: The MPI Standard was unclear on whether this routine required the user to call MPI_Errhandler_free once for each call made to this routine in order to free the error handler. After some debate, the MPI Forum added an explicit statement that users are required to call MPI_Errhandler_free when the return value from this routine is no longer needed. This behavior is similar to the other MPI routines for getting objects;for example, MPI_Comm_group requires that the user call MPI_Group_free when the group returned by MPI_Comm_group is no longer needed. * When calling MPI_File_set_view, mpich currently makes a copy of the etype and filetype if they are derived datatypes (it doesn't matter for named datatypes since they cannot be freed anyway); This frees the user of having to keep the datatype around until the view is reset or until the file is closed. It is also consistent with the behavior of the nonblocking send and receive functions. I would suggest to always return a copy, since: - It clealy is the expected behavior (see examples mentioned above) - There aren't any performance issues with returning a copy. - All existing code would continue to work and be compliant with the modified standard: a copy would always qualify as a derived datatype, and cause MPI_File_get_view users that are currently testing for derived datatypes to free the returned types. (Exception: a code only using predefined datatypes in MPI_File_set_view and assuming that the return types of MPI_File_get_view consequently never need to be freed, could - depending on the implementation - experience either a memory leak or a non-zero reference count on predefined datatypes. Greetings, Dries Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm