[Mpi-22] Another MPI-2.2 attribute ambiguity?
Jeff Squyres
jsquyres at [hidden]
Fri May 22 09:51:27 CDT 2009
Bill and I chatted on the phone a bit -- this is rapidly evolving into
a complex issue. :-)
Let me chat with Iain about this a bit more and get back to the group
-- this may turn into a topic of discussion at the next Forum meeting.
On May 22, 2009, at 10:08 AM, William Gropp wrote:
> 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
>
>
>
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>
--
Jeff Squyres
Cisco Systems
More information about the Mpi-22
mailing list