Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Compile-time MPI_Datatype checking
From: Dmitri Gribenko (gribozavr_at_[hidden])
Date: 2012-05-31 07:22:33

On Thu, May 31, 2012 at 2:07 PM, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> On May 30, 2012, at 7:04 PM, Dmitri Gribenko wrote:
>> +<li><tt>must_be_null</tt> specifies that the expression should be a null
>> +pointer constant, for example:
>> +
>> +<blockquote>
>> +<pre>
>> +/* In mpi.h */
>> +extern struct mpi_datatype mpi_datatype_null
>> +    __attribute__(( type_tag_for_datatype(mpi, void, must_be_null) ));
>> +
>> +#define MPI_DATATYPE_NULL ((MPI_Datatype) &amp;mpi_datatype_null)
>> +
>> +/* In user code */
>> +MPI_Send(buffer, 1, MPI_DATATYPE_NULL /*, ... */); // warning:
>> +                                                   // was specified but buffer
>> +                                                   // is not a null pointer
> I'm not sure that this is a warning we want to set.
> MPI_<foo>_NULL constants are defined as "invalid handles" -- in most cases, it's an error to pass them to an MPI function (e.g., the MPI_Send example, above, would generate an MPI exception).  They're usually used for comparison.
> I can't think of a case offhand where it's acceptable to pass MPI_DATATYPE_NULL to an MPI function.  I could be missing something, though...  (actually, I guess I can think of some cases -- we have some regression test programs that specifically pass MPI_DATATYPE_NULL, just to ensure that it properly invokes an MPI exception)

I usually pass <NULL, MPI_DATATYPE_NULL> as arguments which are
"significant only at root" and that function call is not in the root
process code path.

> But even so, if one passes MPI_DATATYPE_NULL, the buffer and count arguments will be ignored.  So I don't think that we want to require that MPI_DATATYPE_NULL *requires* a NULL pointer.

It just doesn't make sense to pass non-null pointer and
MPI_DATATYPE_NULL (because null pointer will be ignored). Hence the

>> *** JMS I'm a bit confused as to why 2int got a tag, but the others
>>    did not.  We do have C equivalents for all types -- do you need a
>>    listing of the configure results where we figured out all the C
>>    equivalents?  (i.e., I can look them up for you -- our configury
>>    is a bit... deep :-) )
>> I did not annotate them because those are Fortran types.  If there are
>> some known C equivalents in OpenMPI, I will happily add them.  But
>> please note that if these equivalents are discovered during configure,
>> we can not hardcode them into  Some autoconf macros will be
>> needed probably.
> We should have AC macros for all of these already.

OK, I'll try find them to support (1) usecase described below.

> The point of this is because all MPI datatypes are available in all languages, meaning that I could MPI_Send an MPI_INTEGER from fortran and receive it in C code (that MPI_Recv's an MPI_INTEGER).  FWIW, I've seen apps do this in two general cases:
> 1. Fortran sends to C, C just holds the blob without looking at/understanding the value, C eventually sends the blob back to Fortran.
> 2. Fortran sends to C, and C interprets the value because it knows the interoperable type (e.g., sends MPI_INTEGER, receives into a C int).
> If the app doesn't know the exact equivalent C type corresponding to the Fortran type (e.g., case 1), they may need one of the examples I provided above (e.g., cast the buffer to (void*)).



(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr_at_[hidden]>*/