April 2011 - mpi-forum - mailman3.cels.anl.gov

automating building PDFs?
by Fab Tillier 25 Apr '11

25 Apr '11

Hi Folks, Perhaps a bit of an odd request, but maybe other members would benefit from this... Would anyone be able to setup a web form whereby I could specify an SVN branch, submit the form, and have it send me the build output/PDF? If I could provide a patch file as input that would be ideal, as it would let me test my changes before checking them in. I tried a LaTeX package for Windows but it failed to build the document because it only processed the tex files and didn't know how to generate the figures. I haven't found a command line package that I can use that would support our makefile format. This leaves me in the undesirable position of having to impose on other people to not only build PDFs for me, but suffer my LaTeX syntax errors too. Thanks, -Fab

1 0

const correct C-bindings PDF available (reading next meeting)
by Fab Tillier 25 Apr '11

25 Apr '11

The const ticket, ticket 140 (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/140) is ready for its first reading at the May meeting in two weeks. Please find the PDF for review at: https://svn.mpi-forum.org/trac/mpi-forum-web/raw-attachment/ticket/140/tick… Many thanks to Jeff for getting this built and posted. -Fab

1 0

Re: [Mpi-forum] Ticket 265 - Re: Changelog question
by Fab Tillier 25 Apr '11

25 Apr '11

The changelog has been condensed as you suggested, and Jeff kindly built and attached a new PDF to the ticket. -Fab Rolf Rabenseifner wrote on Mon, 25 Apr 2011 at 04:55:36 > Jeff and Fab, > > I would say that the content is fine, but it would also be as > same as good when you combine and shorten some entries, to reduce > the total number to 2 entries, and I would add a simple sentence > about compatibility in the last one: > > 2. Sections 2.5.8, 3.2.2, 3.3 on pages 16, 29, 31, Sections 4.1.5, > 4.1.7, 4.1.8, 4.1.11, 5.9.2 on pages 97, 99, 101, 105, 172, Section 12.3 > on page 412, and Appendix A.1.1 on page 545. New inquiry functions, > MPI_TYPE_SIZE_X, MPI_TYPE_GET_EXTENT_X, MPI_TYPE_GET_TRUE_EXTENT_X, and > MPI_GET_ELEMENTS_X, return their results as an MPI_Count value, which is > a new type large enough to represent element counts in memory, file > views, etc. A new function, MPI_STATUS_SET_ELEMENTS_X, modifies the > opaque part of MPI_STATUS so that a call to MPI_GET_ELEMENTS_X returns > the provided MPI_Count value. > > 3. Sections 3.2.5, 4.1.5, 4.1.11, 4.2 on pages 34, 97, 105, and 127. The > functions MPI_GET_COUNT, MPI_TYPE_SIZE, MPI_GET_ELEMENTS, and > MPI_PACK_SIZE are now defined to set the count, resp. size parameter to > MPI_UNDEFINED when that parameter would overflows. In all other MPI-2.2 > routines, the type and semantics of the count arguments are kept > unchanged, i.e., int or INTEGER. > > ----- > With this all locations are mentioned, all new functionality is mentioned, > and that's what is needed for both users and implementors. > Details can be taken from the cited sections. > > I'm sorry for the late answer - first I've overseen the mail > (therefore I now added "Ticket 265" in the Subject) > - and second, I'm still on Easter break. > > Best regards > Rolf > > ----- Original Message ----- >> From: "Jeff Squyres" <jsquyres(a)cisco.com> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Friday, April 22, 2011 5:11:26 PM >> Subject: Re: [Mpi-forum] Changelog question >> Rolf -- How's this? (see attached; the rendered text didn't >> copy-n-paste well into a plain-text email) >> >> I honestly don't have too much of an opinion here -- Fab and I put >> together what we think Rolf wanted, but it *does* seem like a little >> overkill. >> >> The only think I have a slight reservation about is that this sets a >> high bar for all other MPI-3 proposals -- e.g., will the one-sided >> chapter need to have changelog entries for every new function (because >> they're interleaved; it's not like NBC or MPI_T that just added whole >> new sections). >> >> Or should we have a single new changelog entry, perhaps with a table >> or list of all the new functions? >> >> (I see that Rolf made 13 new changelog entries for the Fortran 08 stuff >> -- https://svn.mpi-forum.org/trac/mpi-forum-web/raw- >> attachment/ticket/229/mpi-report-F2008-2011-04-21-reviewdoc.pdf) >> >> >> >> >> On Apr 21, 2011, at 7:15 AM, Rolf Rabenseifner wrote: >> >>> Yes, of course, but I thought that the MPI_Count >>> ticket has only about 6 new routines, similar to the >>> two entries 17 and 18 on MPI-2.2 pages 594 and 595 >>> about the MPI_DIST_GRAPH_... routines. >>> >>> If a whole new main chapter is added, then >>> typically only one ticket is added, >>> without mentioning 20 routines. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Re: [Mpi-forum] MPI attribute callback behavior
by Dave Goodell 25 Apr '11

25 Apr '11

Jeff, I think I agree with all of your conclusions from this original email, but I don't necessarily agree with your justification for some of them. Mainly, the deletion callbacks can be invoked even when the object itself isn't being freed (via MPI_<FOO>_delete_attr, for example). So justifications like "why allow setting an object that is being deleted?" strike me as invalid. I think a better case for disallowing these sorts of actions is that (1) there seems to be no compelling use case for them, and (2) it could be tricky to correctly handle these cases because they could easily result in recursion in the attribute/callback mechanisms. -Dave On Apr 14, 2011, at 9:36 AM CDT, 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(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] MPI attribute callback behavior
by Jeff Squyres 25 Apr '11

25 Apr '11

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(a)cisco.com >>>>>>> For corporate legal information go to: >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Squyres >>>>>> jsquyres(a)cisco.com >>>>>> For corporate legal information go to: >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] MPI attribute callback behavior
by Bronis R. de Supinski 25 Apr '11

25 Apr '11

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(a)cisco.com >>>>>> For corporate legal information go to: >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Squyres >>>>> jsquyres(a)cisco.com >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > >

1 0

Re: [Mpi-forum] MPI attribute callback behavior
by Jeff Squyres 25 Apr '11

25 Apr '11

...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(a)cisco.com >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>> >>>> >>>> >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] MPI attribute callback behavior
by Bronis R. de Supinski 25 Apr '11

25 Apr '11

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(a)cisco.com >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > >

1 0

Re: [Mpi-forum] MPI attribute callback behavior
by Jeff Squyres 25 Apr '11

25 Apr '11

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(a)cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] MPI attribute callback behavior
by Bronis R. de Supinski 25 Apr '11

25 Apr '11

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(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0