[Mpi3-tools] reviewing the document

[Martin Schulz]

Hi all,

On Jan 25, 2011, at 3:58 PM, Dave Goodell wrote:

> On Jan 25, 2011, at 5:35 PM CST, Jeff Squyres wrote:
> 
>> 1. There's no such thing as an "MPI resource".  The spec defines "MPI handles" and "MPI objects"; we need to couch our definitions in those terms.  I submitted some suggested text to Martin for section 1.2.2, but did not have time to apply it to the rest of the document.
> 
> Agreed.

I will try to make it through the whole document to make that change.
The more I think about it, the more I am convinced we need this
fixed before sending it out to everyone.

> 
>> 2. There's currently no way to free MPIT_MPI_Resource handles (see #3 before saying that you don't need this :-) ).
>> 
>> 3. MPICH may not need real handles for MPIT_MPI_Resource instance (because they're bit-mapped integers), but pointer-driven MPI implementations like Open MPI (may) need at least 2 values: the handle and the type of the handle.  Hence, you need to be able to free MPIT_MPI_Resource handles.
> 
> Technically, even if you have an Open MPI-esque implementation, you could implement your MPI object structs s.t. they have a common header containing RTTI and then gently cheat on C's strict-aliasing rules.  This would avoid the allocation issues.  However, I'm guessing that things aren't already implemented this way for you and such a change could be fairly intrusive.

Yes, Jeff and I talked about this as well and he wasn't sure if this is
the case right now in Open MPI. Even if it would, other implementations
may not have done it that way and it would be a major pain for them
to change.

> 
>> 4. I'm really re-thinking the whole idea that the functions in 1.2.2 provide compile-time type safety.  Specifically: I don't think that they do.  Sure, you're protected from this kind of bozo error:
>> 
>> MPIT_MPI_Resource_communicator(MPI_INT, ...);
>> 
>> but you're not protected from this kind of IMNSHO-more-insidious error:
>> 
>> MPIT_MPI_Resource_communicator(MPI_COMM_WORLD, &foo);
>> MPIT_Perfvar_handle_allocate(x, y, foo, &handle);
>> 
>> where (x, y) refers to a performance variable associated with MPI datatypes.
>> 
>> Sure, you'll get a run-time error, but what did we really gain with the conversion function there?  The conversion function is acting like a cast -- nothing more.  And just like a real casting operator, it (effectively) tells the compiler "don't worry, I know what I'm doing -- don't complain about types here."  I.e., we give up the compile time type safety.  You can still hose yourself w.r.t. the foo MPIT handle and get no protection from the compiler.
>> 
>> So why have it?
> 
> I agree, I don't really see the justification for the N routines, as I indicated on the concalls.
> 
>> I'm wondering if there are really two options here:
>> 
>> 1. Have a real casting operating (somewhat akin to Martin's initial proposal): have a casting function that returns the OUT value (vs. an int error code).  Then you can nest the output of the casting function as an argument to MPI_Perfvar_handle_allocate(), for example.
>> 
>> 2. Have 9 different versions of MPI_Perfvar_handle_allocate() and MPI_Controlvar_handle_allocate() -- one for each MPI handle type.
>> 
>> I assume most people will recoil from #2.  But... hmm.  It *is* the safest way to go.  But ugly (because it's lots of functions).  Hmm...
> 
> #1 is cute, but it doesn't match MPI error handling conventions, and I'd rather not begin passing the error code back as an OUT arg for just this small set of conversion routines.
> 
> #2 is horrifying, we will be laughed at for years to come if we attempt something like this.

There is one other alternative, although, I have to say upfront that I am
not a fan of it: we could provide a unified handle allocation routine for
both control and performance variables. In this case, we would have
to pass an additional argument that specifies whether the index is
a control or performance variable - and that's the part I think is ugly.
However, in this case we would only need one routine per object
type, not two.

> 
> My vote is still for one of the following:
> 
> 3. No conversion routines, just a (void*) arg and assume that the implementation will provide any reasonable amount of runtime type checking that it can.  This would work fine for MPICH2 at least, but I think that the resource args to the *var_handle_allocate routines isn't very self-explanatory in this case.
> 
> 4. A single conversion routine that takes a (void*) and a constant indicating the type of the input pointer.  Like this:
> 
>  int MPIT_Convert_object(void *object_ptr, int obj_type, MPIT_MPI_Resource *resource);
> 
> (rename resource appropriately once you decide what you want to call it)  This at least makes it somewhat clear to new users what the handle_allocate routines are expecting.

If we provide any kind of conversion routine that returns a
new, generic object we will have to deal with a matching
free routine. This will also open questions like, what happens
if the object is freed, but not the generic resource derived
from it? I think this can get messy.

Based on all this discussion, I am starting to lean back towards
just having a void* in the handle allocation routines. If we
can't get full type safety anyway without being laughed at,
then we might as well take the simplest approach.

Martin



> 
> -Dave
> 
> 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA