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

Re: [Mpi-forum] First reading: Remove NBC C++ bindings
by Jeff Squyres 14 Apr '11

14 Apr '11

Should be short. 15 mins? I'll even take a lunch slot. :-) On Apr 14, 2011, at 2:44 PM, Graham, Richard L. wrote: > How much time do you want ? We can schedule this at 3pm on Wed. > > Rich > > On Apr 14, 2011, at 8:44 AM, Jeff Squyres wrote: > >> Rich -- >> >> Is it possible to get a small amount of time for a first reading of ticket #272? >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/272 >> >> The ticket is very simple: the removal of the C++ bindings from the non-blocking collectives (in order to be consistent with the rest of the MPI-3.0 lack of new C++ bindings). History and rationale is explained on the ticket. A colorized PDF is attached to the ticket. >> >> The "reading" is trivial -- it's simply the removal of the NBC C++ bindings. There's no other supporting text that needs to be modified. >> >> -- >> 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] First reading: Remove NBC C++ bindings
by Graham, Richard L. 14 Apr '11

14 Apr '11

How much time do you want ? We can schedule this at 3pm on Wed. Rich On Apr 14, 2011, at 8:44 AM, Jeff Squyres wrote: > Rich -- > > Is it possible to get a small amount of time for a first reading of ticket #272? > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/272 > > The ticket is very simple: the removal of the C++ bindings from the non-blocking collectives (in order to be consistent with the rest of the MPI-3.0 lack of new C++ bindings). History and rationale is explained on the ticket. A colorized PDF is attached to the ticket. > > The "reading" is trivial -- it's simply the removal of the NBC C++ bindings. There's no other supporting text that needs to be modified. > > -- > 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] First reading: Remove NBC C++ bindings
by Pavan Balaji 14 Apr '11

14 Apr '11

On 04/14/2011 09:50 AM, Jeff Squyres wrote: > So rather than anticipating what *might* happen with their ticket > (it's still in the "unready" state after nearly a year), I figured > I'd file a trivial ticket to make MPI-3.0 consistent with respect to > the C++ bindings. Ok, that's fair enough. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] First reading: Remove NBC C++ bindings
by Jeff Squyres 14 Apr '11

14 Apr '11

On Apr 14, 2011, at 10:43 AM, Pavan Balaji wrote: > I don't think any decision was made, but there was discussion on this point a few Forums back. I think Tony (?) mentioned that he'll put together a ticket to undeprecate them. Your ticket is certainly valid at this point, but it might be better to coordinate with him to avoid wasted effort. I've talked to Rich and Tony a few times; they've not made any forward progress on their ticket. So rather than anticipating what *might* happen with their ticket (it's still in the "unready" state after nearly a year), I figured I'd file a trivial ticket to make MPI-3.0 consistent with respect to the C++ bindings. -- 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] First reading: Remove NBC C++ bindings
by Pavan Balaji 14 Apr '11

14 Apr '11

Hi Jeff and Jeff, On 04/14/2011 08:15 AM, Jeff Squyres wrote: > On Apr 14, 2011, at 8:54 AM, Jeff Hammond wrote: > >> I thought the Forum decided to un-deprecate the C++ bindings, or at >> least had a straw vote expressing intent to do this. If that is the >> case, C++ bindings should be defined for all 3.0 functionality. > > I'm unaware of any such decision being made. I don't think any decision was made, but there was discussion on this point a few Forums back. I think Tony (?) mentioned that he'll put together a ticket to undeprecate them. Your ticket is certainly valid at this point, but it might be better to coordinate with him to avoid wasted effort. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

MPI attribute callback behavior
by Jeff Squyres 14 Apr '11

14 Apr '11

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/

1 0

Re: [Mpi-forum] First reading: Remove NBC C++ bindings
by Jeff Squyres 14 Apr '11

14 Apr '11

On Apr 14, 2011, at 8:54 AM, Jeff Hammond wrote: > I thought the Forum decided to un-deprecate the C++ bindings, or at > least had a straw vote expressing intent to do this. If that is the > case, C++ bindings should be defined for all 3.0 functionality. I'm unaware of any such decision being made. And to clarify: the new ticket is to make the NBC stuff consistent with everything else that is happening in MPI-3.0 (i.e., no new C++ bindings). It's only due to a quirk of timing that the MPI-3.0 NBC text was accepted with new functions that included C++ bindings. > I come to less than half the Forum meetings, so can someone point me > to the content that explains when and how the tide turned back towards > MPI not treating C++ as a first-class programming language? Your statement isn't quite fair -- MPI does nothing to disqualify C++ applications. You can (obviously) use the C bindings in a C++ application. And also to be specific: the C++ bindings are not being withdrawn; they are deprecated, meaning that they *might* be removed someday (not by me, and I don't know anyone who is willing to undertake the effort -- it would be a LOT of text to edit). And no new C++ bindings will be introduced. See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/150 for some details about the 2.2 deprecation of the C++ bindings. The general feelings were: - the C++ bindings have caused *considerable* maintenance over the years (including several ill-informed / incorrect errata email votes in the late '90s) - the C++ bindings provide very little semantic difference over the C bindings - plans for the C++ bindings to be building blocks for more expressive C++ class libraries essentially failed (e.g., Boost.MPI uses the C bindings) - more expressive C++ MPI class library functionality is both out of scope of the MPI specification and is available elsewhere -- 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] First reading: Remove NBC C++ bindings
by Jeff Hammond 14 Apr '11

14 Apr '11

I thought the Forum decided to un-deprecate the C++ bindings, or at least had a straw vote expressing intent to do this. If that is the case, C++ bindings should be defined for all 3.0 functionality. I come to less than half the Forum meetings, so can someone point me to the content that explains when and how the tide turned back towards MPI not treating C++ as a first-class programming language? Jeff On Thu, Apr 14, 2011 at 7:44 AM, Jeff Squyres <jsquyres(a)cisco.com> wrote: > Rich -- > > Is it possible to get a small amount of time for a first reading of ticket #272? > > ï¿½ ï¿½https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/272 > > The ticket is very simple: the removal of the C++ bindings from the non-blocking collectives (in order to be consistent with the rest of the MPI-3.0 lack of new C++ bindings). ï¿½History and rationale is explained on the ticket. ï¿½A colorized PDF is attached to the ticket. > > The "reading" is trivial -- it's simply the removal of the NBC C++ bindings. ï¿½There's no other supporting text that needs to be modified. > > -- > 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 > -- Jeff Hammond Argonne Leadership Computing Facility jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond

1 0

First reading: Remove NBC C++ bindings
by Jeff Squyres 14 Apr '11

14 Apr '11

Rich -- Is it possible to get a small amount of time for a first reading of ticket #272? https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/272 The ticket is very simple: the removal of the C++ bindings from the non-blocking collectives (in order to be consistent with the rest of the MPI-3.0 lack of new C++ bindings). History and rationale is explained on the ticket. A colorized PDF is attached to the ticket. The "reading" is trivial -- it's simply the removal of the NBC C++ bindings. There's no other supporting text that needs to be modified. -- 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] Comment on Fortran WG5 ballot N1846
by N.M. Maclaren 14 Apr '11

14 Apr '11

On Apr 14 2011, Rasmussen, Craig E wrote: > >>Programs are prohibited from causing definitions or references that >>could result in a race condition. > > But this part of the standard only seems to put limitations on a > variable. So there should be other ways to express what we want. > Consider: > >BLOCK > target :: A real, target :: A(6) ! I assume > real, pointer, ASYNCHRONOUS :: ptr(:) > > ptr => A(1:5) > > ! asynchronous communication with MPI and ptr variable > > A(6) = 1.0 > > MPI_Wait() > >END BLOCK > >What is your interpretation of the example? It looks fine to me, but I accept that it is not obvious. Remember that a Fortran variable isn't like a variable in other languages, so I read the program as follows: 'A' is a variable, but is not accessed except through selectors, so is not directly involved. 'A(1:5)' is another variable, though it is associated with 'A'. 'ptr' is another variable, which is associated with 'A(1:5)' and flagged as asynchronous, so can be used in that way. 'A(6)' is another variable. Despite the fact that it is also associated with 'A', it is NOT associated with 'A(1:5)' and so there is no race condition. Now, I may well have misunderstood the standard, but that is how I read the intent. I can easily believe that the actual wording needs some clarification (a universal statement!), but I don't think that any change is needed. Regards, Nick Maclaren.

1 0