[Mpi3-tools] reviewing the document
goodell at mcs.anl.gov
Tue Jan 25 17:58:27 CST 2011
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.
> 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.
> 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.
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.
More information about the mpiwg-tools