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

[Jeff Squyres]

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