Re: Attribute caching fuzzyness

Marc Snir (snir@watson.ibm.com)
Mon, 31 Mar 1997 18:46:40 -0400




......

In:
MPI_Keyval_create(....,&mykey,..);
MPI_Attr_put(comm,mykey,attr);
MPI_Keyval_free(&mykey);
MPI_Comm_dup(comm, &newcom);
the value of mykey has been changed to MPI_KEYVAL_INVALID so if I have
doubt about using "keyval" I can check its validity before using it. The
call to MPI_Comm_dup will cause the copy function originally bound to
mykey to be called and that copy_fn will be
passed an alias with the original keyval. There will be no indication
that the value now represents a key which has been freed and cannot be
used in an MPI call.

*****
The call to MPI_Comm_dup should cause the copy_fn function originally bound
to mykey to be called, and to be passed a valid attribute: comm still
carries an attribute associated with mykey when Comm_dup is invoked. The
only way for the user to explicitly access the newly created attribute that
is associated with keyval and newcomm is to use an MPI_Attr_get(newcomm,
mykey,&flag) call, and this is clearly erroneous, after a call to
MPI_Keyval_free(&mykey). This may be silly, but it works. I only see a
problem if the callback function itslef tries to attributes associated with
keyval -- but why should it?
*******