[Mpi3-tools] reviewing the document

[Jeff Squyres]

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

>> 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.

You're completely right; I typed my message in haste last night and meant to say pretty much exactly what you did, but forgot.

I mentioned to Martin multiple times that I need to check OMPI and see if we did what you mentioned (have some kind of member right up at the top of all MPI object such that we could figure out its type if we were given just a pointer).  I'm not sure that we did, nor what the consequences would be if we grafted such a scheme into the current code base (i.e., I just haven't thought about it yet).

>> [snip]
>> 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.

MPI_Wtick, MPI_Wtime, and the f2c / c2f routines return their OUT values.  Indeed, the f2c / c2f routines could be considered "casting-like" operators.

> #2 is horrifying, we will be laughed at for years to come if we attempt something like this.

Maybe.

But consider that overloading languages like C++ effectively do the same thing; they just have a nice language-built-in-function that all N functions *look* like 1 function.  But they're really still implemented (and possibly described) as N different functions, with (potentially) different implementations and logic.

> 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.

I'm not sure that that's a good or a bad assumption (that's not a snarky comment -- I'm honestly not sure).  As mentioned above, I have to think about whether we can do that in OMPI or not, for example.

> 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);

That would certainly be safer than #3, even if the obj_type is effectively redundant (other than perhaps an additional error/consistency check) in some implementations like mpich2.

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/