[Mpi-forum] MPI attribute callback behavior

Bronis R. de Supinski bronis at llnl.gov
Mon Apr 25 11:30:37 CDT 2011


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.

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/
>
>



More information about the mpi-forum mailing list