[MPI3 Fortran] Fortran extra_state argument to MPI attribute functions
longb at cray.com
Sun May 31 15:41:53 CDT 2009
Jeff Squyres wrote:
> Specifically, there is no indication of how the "extra_state"
> parameter is handled when it is passed to callback functions.
> Bear with me -- this requires a little explanation...
> The issue is this: when you create a "keyval" in MPI, you specify 2
> callback functions and an INTEGER extra_state parameter. Each of the
> two callback functions has an extra_state parameter; the intent is
> that the extra_state from the keyval creation function is passed as
> the argument to these two callback functions. Here's a sample keyval
> ! copy_fn and delete_fn are subroutines
> ! comm is an INTEGER
> INTEGER extra_state
> extra_state = 42
> CALL MPI_Comm_create_keyval(copy_fn, delete_fn, comm, extra_state,
> extra_state = 17
I read though some sections of the MPI document to try to figure out
what an "attribute" was - evidently some new component you add to an
object. I still don't know what an "attribute key" is - the name
suggests something to do with encryption. I'll assume that's not
important. The document also says that "callback" routines may be
associated with MPI objects (a communicator in this case). I'm guessing
the extra_state is some identifier that is associated with an attribute
that is created somewhere else.
> However, the original intent is somewhat lost here -- since the
> MPI_COMM_CREATE_KEYVAL interface specifies that the EXTRA_STATE
> parameter is an integer, how can you pass a reference to a larger /
> external structure? This seems somewhat broken / inconsistent with
> the intent from the C interface.
> Of course, you *could* pass an INTEGER EXTRA_STATE value that is an
> index into a global array in the application that contains some
> reference to an external data instance -- but that seems fairly
> manual. Is there a better way?
> How are such things normally done in Fortran? (meaning: what *should*
> we do here?)
Assuming my impressions above are close to correct, then I think this is
yet another example of an underlying defect in the MPI Fortran
interfaces - the basic denial that derived types exist in Fortran. From
Fortran's point of view, all of the routines along the lines of
MPI_Comm_create_keyval should be removed. Instead, a derived type for
a communicator, MPI_comm_t, should be defined in the MPI module. If
users want to add information to the communicator, they can define a new
type that extends MPI_comm_t by adding the desired components, and an
additional interface (and routine, if needed) for the generic binding
copy_fn that indicates how to copy these components, and add an
interface to the final binding that performs the delete_fn operation.
Specify the communicator dummy arguments as class(MPI_comm_t).
As historical note, the POSIX Fortran bindings were written only a few
years after derived types were added to Fortran, and the debate settled
on not admitting they existed so as to be "safe". (There are people
still using f77!!!, so I'm told the argument went.) The result is a
ridiculous mess that's been the butt of derision for years since. And,
disuse, I might add. Fortran 2003 has been published for 5 years. We
should not be afraid to use its features if they turn out to provide the
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the mpiwg-fortran