Date: Fri, 9 Feb 2001 13:37:18 -0500
From: Nicholas Nevin - Sun HPC High Performance Computing <Nicholas.Nevin@XXXXXXXXXXXX>
To: Rolf Rabenseifner <Rabenseifner@XXXXXXXXXXXXXXXXXXXX>
Cc: Nicholas Nevin - Sun HPC High Performance Computing <Nicholas.Nevin@XXXXXXXXXXXX>,Subject: Re: MPI-2 standard issues - MPI_Type_create_f90_...
References: <20010209111839.F20056@caja> <200102091701.SAA31208@XXXXXXXXXXXXXXXXXXXXXXXXXX>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.9i
In-Reply-To: <200102091701.SAA31208@XXXXXXXXXXXXXXXXXXXXXXXXXX>

On Fri, Feb 09, 2001 at 06:01:39PM +0100, Rolf Rabenseifner wrote:
> [I'm splitting the stream by using a new subject]
>  
> Nick: 
> > > >2. Why the restriction that types obtained from calls to
> > > >MPI_Type_create_f90_{real,complex,integer} cannot be freed? This
> > > >restriction doesn't appear to serve any useful purpose and the
> > > >requirement that MPI_Type_get_envelope return the precision/range used
> > > >to create such a type seems to either require an implementation to
> > > >maintain a potentially very large table or allocate dynamic storage
> > > >(which cannot be freed) to store the precision/range.
> 
> Bill: 
> > > This looks like a mistake.  A correction could say that the type returned 
> > > is effectively a dup of the predefined type, it can (and should be) freed 
> > > by the user, and implementer could use internal attributes to store the 
> > > info needed for MPI_Type_get_envelope.  Note that for layered libraries on 
> > > heterogeneous system, it is necessary to provide the features specified for 
> > > MPI_Type_get_envelope.
> 
> Nick:
> > I'm happy with such a correction.
> 
> Sorry, but this would really change the MPI-2 standard.
> MPI-2 allows to return always the same handle, and not a dup.
> And to save memory, the best is that
>  
>  - MPI_Type_get_envelope returns the original (predefined) handle 
>    and not a dup (no costs!) 


Only for predefined types.


>    (--> therefore no reason for freeing it!) 
>  
>  - and MPI_Type_create_f90_{real,complex,integer} should check 
>    whether it has already returned a predefined handle with
>    the same semantics. May cost typically a small search,
>    because application will not use dozens of such datatypes.  
>    For this purpose, you need to link your predefined dataypes
>    in a list or to setup a small hash table. Not more. 
> 
> With this, you have no problem with 
> - the MPI-2 standard (p.295, line 32 "They cannot be freed;") and
> - the MPI-1 standard (p.8, line 36 "Such objects [predefined opaque 
>   objects] may not be destroyed.")
> 
> Is this okay or have I make a mistake?
> Rolf 
>  


I don't think that the proposed correction changes the standard significantly.
Programs which currently work should continue to work and the proposed change will
allow proper cleanup by applications which wish to do so.

IMO standards should not rely on assumptions like the one you make above,
i.e. "application will only use dozens of such datatypes".

Note that the requirements for MPI_Type_get_contents also
mean that MPI_Type_create_f90_* must return a distinct handle for each
possible range/precision. If these handles cannot be freed this could
cause problems for implementations which restrict the number of handles
which can be in use at any one time.

-nick