[Mpi-22] Another MPI-2.2 attribute ambiguity?
Jeff Squyres
jsquyres at [hidden]
Tue May 26 11:47:06 CDT 2009
This got even more complex when I talked to Iain on the phone. We're
going to move this conversation to the MPI Fortran working group list
(mpi3-fortran).
In case you didn't catch it before, this is quite definitely an MPI-3
item.
On May 22, 2009, at 10:51 AM, Jeff Squyres wrote:
> 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
>
> _______________________________________________
> 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