[Mpi-forum] MPI attribute callback behavior

[Jeff Squyres]

On Apr 25, 2011, at 12:30 PM, Bronis R. de Supinski wrote:

> I am saying I woukd favor making it invalid as it
> still requires modification. I am fine with your
> analysis of the other items on the list.

Sounds good; thanks.

I'll make up a ticket for the list, and include MPI_<foo>_FREE in there as well.  Won't make it for this meeting, though -- I think the agenda's already way too full.


> On Mon, 25 Apr 2011, Jeff Squyres wrote:
> 
>> ...so are you saying that you think it's valid or invalid to call MPI_COMM_FREE in the callbacks in this case?
>> 
>> What do you think about the rest of the items in the list?
>> 
>> 
>> On Apr 25, 2011, at 12:01 PM, Bronis R. de Supinski wrote:
>> 
>>> 
>>> Hmm. You still modify A and B but I guess the mods
>>> are not visible by that logic.
>>> 
>>> On Mon, 25 Apr 2011, Jeff Squyres wrote:
>>> 
>>>> Probably.
>>>> 
>>>> But here's the kicker: MPI_COMM_FREE only *marks* a communicator for freeing; it doesn't necessarily actually free it.
>>>> 
>>>> That's my only pause in thinking that it *could* be valid to call MPI_COMM_FREE on a communicator in an attribute callback related to that communicator.
>>>> 
>>>> (ditto for TYPE_FREE and WIN_FREE)
>>>> 
>>>> 
>>>> On Apr 25, 2011, at 11:53 AM, Bronis R. de Supinski wrote:
>>>> 
>>>>> 
>>>>> Jeff:
>>>>> 
>>>>> Maybe I am not following. Wouldn't it be illegal based
>>>>> on your original reasoning for B (it is still being
>>>>> created so the delete is non-deterministic) and for A
>>>>> (seems like a bad idea to modify, i.e., delete, what
>>>>> you are in the middle of copying).
>>>>> 
>>>>> Bronis
>>>>> 
>>>>> 
>>>>> On Mon, 25 Apr 2011, Jeff Squyres wrote:
>>>>> 
>>>>>> Here's a followup question: is it valid to call MPI_COMM_FREE on objects A or B when in a keyval copy callback with original object A and new object B?
>>>>>> 
>>>>>> I can't decide whether the answer should be "yes" or "no"...
>>>>>> 
>>>>>> 
>>>>>> On Apr 14, 2011, at 10:36 AM, Jeff Squyres wrote:
>>>>>> 
>>>>>>> An issue recently came up within Open MPI as to what exactly you are allowed to do within an attribute callback (e.g., when a communicator is copied or deleted).
>>>>>>> 
>>>>>>> From a standards point of view (i.e., regardless of implementation), here's a list that we came up with:
>>>>>>> 
>>>>>>> 1. While in a keyval copy callback with original object A and new object B:
>>>>>>> - Call MPI_Comm_get_attr on A: ok
>>>>>>> - Call MPI_Comm_get_attr on B: erroneous
>>>>>>> (B is still being created, and therefore the get is non-deterministic)
>>>>>>> - Call MPI_Comm_set_attr on A: erroneous
>>>>>>> (seems like a bad idea to modify what you're in the middle of copying)
>>>>>>> - Call MPI_Comm_set_attr on B: erroneous (non-deterministive) if keyval exists on A, otherwise ok
>>>>>>> - Call MPI_Comm_delete_attr on A: erroneous
>>>>>>> (seems like a bad idea to modify what you're in the middle of copying)
>>>>>>> - Call MPI_Comm_delete_attr on B: erroneous (non-deterministic)
>>>>>>> (same as get_attr on B, above)
>>>>>>> - Call MPI_Comm_create_keyval: ok
>>>>>>> - Call MPI_Comm_free_keyval: ok
>>>>>>> 
>>>>>>> 2. While in a keyval delete callback on object A:
>>>>>>> - Call MPI_Comm_get_attr on A: erroneous
>>>>>>> (A is being deleted; that attribute may have already been deleted)
>>>>>>> - Call MPI_Comm_set_attr on A: erroneous
>>>>>>> (why allow setting on an object that is being deleted?)
>>>>>>> - Call MPI_Comm_delete_attr on A: erroneous
>>>>>>> (it's going to be deleted anyway)
>>>>>>> - Call MPI_Comm_create_keyval: ok
>>>>>>> - Call MPI_Comm_delete_keyval: ok
>>>>>>> 
>>>>>>> Does anyone disagree with this list?
>>>>>>> 
>>>>>>> Should we put some kind of list like this in MPI-3?  (I can work up a ticket if we think supporting text like this should be there)
>>>>>>> 
>>>>>>> --
>>>>>>> Jeff Squyres
>>>>>>> jsquyres at cisco.com
>>>>>>> For corporate legal information go to:
>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Jeff Squyres
>>>>>> jsquyres at cisco.com
>>>>>> For corporate legal information go to:
>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> mpi-forum mailing list
>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>> 
>>>>> _______________________________________________
>>>>> mpi-forum mailing list
>>>>> mpi-forum at lists.mpi-forum.org
>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>> 
>>>> 
>>>> --
>>>> Jeff Squyres
>>>> jsquyres at cisco.com
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>> 
>>>> 
>> 
>> 
>> -- 
>> Jeff Squyres
>> jsquyres at cisco.com
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> 


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/