In C, the extra state is passed to MPI_Keyval_create as a void* and also
to the copy & delete functions as a void*. This would imply to a C
programmer that some storage is to be allocated before the keyval_create
and maintained until after the final invocation of any copy or delete
function related to that key. It would also imply that the extra_state
could contain data which both the callback functions and mainline code
can examine/update. Seems clear enough.
1) In Fortran the extra state is passed to MPI_KEYVAL_CREATE as an
integer with no indication I could find whether the programmer is to
view that as a value or a reference. Can the fortran program pass "3"
as extra state or must it pass an integer which MPI will keep an address
for and deliver to each callback. I slightly prefer the second but it
does mean the Fortran programmer must understand that the variable to be
used must be one which will remain allocated. (i.e. Not on the stack)
Of course, if this is the intent then the fortran "extra state" might as
well be a <choice> as an integer. With the "value" interpretation, MPI
maintains space for 1 integer which is set to the initial value at rhe
keyval_create. The callbacks can be permitted to read/update it but such
updates will be hidden from the mainline code.
2) MPI_Keyval_free nullifies the handle and marks the attribute object
for deallocation but little is clear about impact on behavior of
attributes which remain on objects. De we assume that attribute copy
and delete functions are still called for the attribute if it is left on
any object which is duped or freed after the Keyval_free? What value is
passed to a copy or delete function for its KEYVAL parameter if the
keyval has been freed? Does MPI guarantee it will be
MPI_KEYVAL_INVALID? An advice to users should probably be added saying
either that they MUST scrub all objects before the MPI_Keyval_free or
stating that a copy/delete function can count on seeing
MPI_KEYVAL_INVALID after a keyval_free and can treat that as a
"never_mind". (other suggestions are welcome)
3) A threaded MPI is probably obliged to make sure that there are not
two callbacks executing at the same time so that any callback can be
coded without adding mutex locks to the update of "extra_state". Even
with this requirement though, a threaded MPI would make a non-callback
update or examination of "extra_state" unsafe. One thread cannot know
when another may be doing an MPI_COMM_DUP for example.
Dick
-- Dick Treumann IBM RS/6000 Division (Internet) treumann@pok.ibm.com Poughkeepsie, NY (VNET) TREUMANN at KGNVMC Tel: (914) 433-7846 (internal) treumann@windsurf.pok.ibm.com Fax: (914) 433-8363