[Mpi-22] Another MPI-2.2 attribute ambiguity?

Fri May 22 09:08:20 CDT 2009

Remember, the primary definition of the MPI routine is the language- 
neutral form.  That specifies a pointer to some extra state, but does  
says nothing about the size of the data to which that points.  I'm  
*sure* that the intention of the language-neutral design was that  
extra state would often be either null or a pointer to a structure  
containing more than one item; the Fortran equivalent to this is an  
array.  In Fortran 77, there is no way to specify what in C is a void  
pointer, so the binding says "pass an address-sized integer" (e.g.,  
something that could be a pointer) and hope for the best.

The point about expressions being passed also applies to C - if you  
pass, as extra state, an address to data that may go out of scope, you  
have a similar problem to passing an expression as extra state in  
Fortran.  More specifically, it is already the case that everything  
which is syntactically allowed is not semantically allowed.  Just  
because it will compile doesn't make it correct MPI code.

There is certainly ambiguity here.  My preference is to start with the  
intent of the language neutral specification and make that work.  That  
may require additional advice to users and implementors about what is  
valid and what is invalid (note that expressions are semantically  
invalid in other places, such as buffers to the non-blocking routines  
in Fortran).

Bill

On May 22, 2009, at 7:39 AM, Jeff Squyres wrote:

> Imagine a Fortran communicator keyval copy function callback like this
> (typed off the top of my head; pardon typos):
>
>       SUBROUTINE COPY_FUNCTION1(OLDCOMM, KEYVAL, EXTRA_STATE, AVALIN,
> AVALOUT, FLAG, IERR)
>       ...
>       INTEGER EXTRA_STATE
>       INTEGER IERR
>       EXTRA_STATE = EXTRA_STATE + 1
>       WRITE *, "Extra state is: ", EXTRA_STATE
>       IERR = MPI_SUCCESS
>       END
>
> Now suppose MPI_COMM_CREATE_KEYVAL is invoked like this:
>
>       INTEGER EV = 7
>       CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV, IERR)
>
> I think we all agree that the output the first time that
> COPY_FUNCTION1 is invoked should be 7.  But what is the output the
> second time it is invoked -- 7 or 8?  That is the question.
>
> I think Iain has conclusively show that in this case:
>
>       INTEGER EV = 7
>       CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV + 3, IERR)
>       EV = 42
>
> the output from the first call to COPY_FUNCTION1 still needs to be 10.
>
> The point is that the MPI implementation needs to *copy* the INTEGER
> value into internal storage and use *that* storage when calling
> COPY_FUNCTION1.  If for no other reason than the value may be the
> result of an expression, and that storage disappears after the call to
> MPI_COMM_KEYVAL_CREATE completes (as in the above example).
>
> I'm not sure what you're referring to with the array stuff -- the
> Fortran prototype for the callback function says that the extra value
> can only be a single INTEGER...?
>
>
>
> On May 21, 2009, at 4:41 PM, William Gropp wrote:
>
>> I'm not sure what "change the value" means in #1.  I think that you
>> mean "if we interpret extra_data as a pointer to a Fortran data item,
>> the MPI implementation will pass this pointer (by value) to the
>> callback.  If the callback stores through this pointer, then
>> (naturally) the afore mentioned data item will be changed.  If that's
>> what #1 means, then yes, that's the right answer.  Note that the
>> extra_data could be a pointer to an array of arbitrary size, and the
>> call back could update any part of the array. Saving a copy of what
>> extra_data points at (is that what #2 is doing?) is going to be
>> tricky, since you don't know the size of the thing to copy (without a
>> lot of help from the compiler in Fortran).
>>
>> Bill
>>
>> On May 19, 2009, at 7:55 PM, Jeff Squyres wrote:
>>
>>> So then you're in favor of #1 from my original post, right?
>>>
>>>    http://lists.mpi-forum.org/mpi-22/2009/05/0407.php
>>>
>>>
>>> On May 19, 2009, at 4:39 PM, William Gropp wrote:
>>>
>>>> Silly me, I missed that.
>>>>
>>>> In Fortran (particularly thinking in terms of Fortran 77, since
>> that
>>>> was the original design), the Fortran callback should be able to do
>>>> things like increment the "extra data" - i.e., if the extra data
>> is a
>>>> counter, the Fortran callback should be able to increment it.
>> Since
>>>> Fortran 77 has no pointers (and pointers in Fortran 90 aren't the
>>>> same
>>>> as addresses), having an address is worthless in a Fortran 77
>>>> program.  So if the MPI implementation stores the address of the
>>>> extra
>>>> data and passes that to the call back (by value, so Fortran sees
>> the
>>>> address of the extra data), users should get what they expect in
>>>> Fortran.
>>>>
>>>> Bill
>>>>
>>>> On May 19, 2009, at 12:22 PM, Iain Bason wrote:
>>>>
>>>>>
>>>>> On May 19, 2009, at 1:16 PM, William Gropp wrote:
>>>>>
>>>>>> MPICH2 passes the value of the extra_state that was saved in the
>>>>>> internal storage to the callback routine, which is case 2 (the
>> copy
>>>>>> is implicit as the value is passed to the routine and C semantics
>>>>>> ensures that the value isn't changed).
>>>>>
>>>>> But this is the Fortran interface, not the C interface.
>>>>>
>>>>> Iain
>>>>>
>>>>
>>>> William Gropp
>>>> Deputy Director for Research
>>>> Institute for Advanced Computing Applications and Technologies
>>>> Paul and Cynthia Saylor Professor of Computer Science
>>>> University of Illinois Urbana-Champaign
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mpi-22 mailing list
>>>> mpi-22_at_[hidden]
>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>>>>
>>>
>>>
>>> --
>>> Jeff Squyres
>>> Cisco Systems
>>>
>>> _______________________________________________
>>> mpi-22 mailing list
>>> mpi-22_at_[hidden]
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>>
>> William Gropp
>> Deputy Director for Research
>> Institute for Advanced Computing Applications and Technologies
>> Paul and Cynthia Saylor Professor of Computer Science
>> University of Illinois Urbana-Champaign
>>
>>
>>
>>
>> _______________________________________________
>> mpi-22 mailing list
>> mpi-22_at_[hidden]
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>>
>
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign