April 2009 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 17 Apr '09

17 Apr '09

Ok, I'll file an MPI-3 ticket for this. (for everyone else on the 2.2 list wondering why you just got blitzkrieged with a whole pile of emails on this topic: the listserver sent all these mails to moderation because of the lengthy CC list. IU just approved all the mails to go through this morning) On Apr 17, 2009, at 9:40 AM, William Gropp wrote: > Yes, this is worth an ATI - the fact that we traded this much mail on > it is proof of that :) > > Thanks, Jeff. > > Bill > > On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote: > > > Someone pointed out to me this morning that there's no restriction > on > > the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may > be an > > expression, for example. I think that pretty much seals the deal > that > > #2 is the correct way. > > > > I think that this is worth an ATI in the text; does anyone disagree? > > I volunteer to write it up/make a 3.0 ticket (hey, first ticket for > > the Misc WG! :-) ) if no one disagrees. > > > > > > On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: > > > >> Hi, > >> > >> Intel MPI (and most likely other MPICH2 derivatives) appears to use > >> method #2. > >> > >> Best regards. > >> > >> Alexander > >> > >> -----Original Message----- > >> From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > >> Sent: Thursday, April 16, 2009 4:19 PM > >> To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; > Hubert > >> Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan > Balaji; > >> Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard > >> Ry; Håkon Bugge > >> Subject: Another MPI-2.2 attribute ambiguity? > >> > >> This is related to -- but different from -- MPI 2.2 ticket #55 > >> ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly > >> adding all the #55 CC members to this mail, plus a few others. > >> > >> I cannot find any text in MPI-2.1 (e.g., p223-225) describing > >> specific > >> behavior regarding the EXTRA_STATE arguments passed to the Fortran > >> keyval copy and delete functions (both the ADDRESS_KIND and > >> deprecated > >> flavors). I see two choices: > >> > >> 1. pass the user's original EXTRA_STATE argument by reference to > the > >> callbacks, or > >> 2. copy the user's original EXTRA_STATE into internal MPI storage > and > >> pass *that* value by reference to the callbacks > >> > >> ==> Open MPI currently does #1. What do other implementations do? > >> > >> I raise this issue because the text does not indicate which way is > >> right. And I just ran across an old Sun test that assumed #2. But > >> our internal copy of the Intel MPI tests assume #1 (to be fair: I > >> have > >> no idea if the Intel tests originally assumed #2 and we changed > them > >> to #1 over time). Indeed, #2 is actually in-line with the > philosophy > >> of storing attribute values in internal MPI storage. E.g.: > >> > >> INTEGER foo = 4 > >> INTEGER bar > >> CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) > >> foo = 5 > >> CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) > >> > >> bar should equal 4, not 5 (right?). > >> > >> So what does that mean (or imply) about the EXTRA_STATE value > passed > >> to the Fortran callbacks? > >> > >> -- > >> Jeff Squyres > >> Cisco Systems > >> > >> > --------------------------------------------------------------------- > >> Intel GmbH > >> Dornacher Strasse 1 > >> 85622 Feldkirchen/Muenchen Germany > >> Sitz der Gesellschaft: Feldkirchen bei Muenchen > >> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > >> Registergericht: Muenchen HRB 47456 Ust.-IdNr. > >> VAT Registration No.: DE129385895 > >> Citibank Frankfurt (BLZ 502 109 00) 600119052 > >> > >> This e-mail and any attachments may contain confidential material > for > >> the sole use of the intended recipient(s). Any review or > distribution > >> by others is strictly prohibited. If you are not the intended > >> recipient, please contact the sender and delete all copies. > >> > >> > > > > > > -- > > Jeff Squyres > > Cisco Systems > > > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 17 Apr '09

17 Apr '09

Yes, this is worth an ATI - the fact that we traded this much mail on it is proof of that :) Thanks, Jeff. Bill On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote: > Someone pointed out to me this morning that there's no restriction on > the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may be an > expression, for example. I think that pretty much seals the deal that > #2 is the correct way. > > I think that this is worth an ATI in the text; does anyone disagree? > I volunteer to write it up/make a 3.0 ticket (hey, first ticket for > the Misc WG! :-) ) if no one disagrees. > > > On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: > >> Hi, >> >> Intel MPI (and most likely other MPICH2 derivatives) appears to use >> method #2. >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: Jeff Squyres [mailto:jsquyres_at_[hidden]] >> Sent: Thursday, April 16, 2009 4:19 PM >> To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert >> Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; >> Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard >> Ry; Håkon Bugge >> Subject: Another MPI-2.2 attribute ambiguity? >> >> This is related to -- but different from -- MPI 2.2 ticket #55 >> ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly >> adding all the #55 CC members to this mail, plus a few others. >> >> I cannot find any text in MPI-2.1 (e.g., p223-225) describing >> specific >> behavior regarding the EXTRA_STATE arguments passed to the Fortran >> keyval copy and delete functions (both the ADDRESS_KIND and >> deprecated >> flavors). I see two choices: >> >> 1. pass the user's original EXTRA_STATE argument by reference to the >> callbacks, or >> 2. copy the user's original EXTRA_STATE into internal MPI storage and >> pass *that* value by reference to the callbacks >> >> ==> Open MPI currently does #1. What do other implementations do? >> >> I raise this issue because the text does not indicate which way is >> right. And I just ran across an old Sun test that assumed #2. But >> our internal copy of the Intel MPI tests assume #1 (to be fair: I >> have >> no idea if the Intel tests originally assumed #2 and we changed them >> to #1 over time). Indeed, #2 is actually in-line with the philosophy >> of storing attribute values in internal MPI storage. E.g.: >> >> INTEGER foo = 4 >> INTEGER bar >> CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) >> foo = 5 >> CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) >> >> bar should equal 4, not 5 (right?). >> >> So what does that mean (or imply) about the EXTRA_STATE value passed >> to the Fortran callbacks? >> >> -- >> Jeff Squyres >> Cisco Systems >> >> --------------------------------------------------------------------- >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen Germany >> Sitz der Gesellschaft: Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer >> Registergericht: Muenchen HRB 47456 Ust.-IdNr. >> VAT Registration No.: DE129385895 >> Citibank Frankfurt (BLZ 502 109 00) 600119052 >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> > > > -- > Jeff Squyres > Cisco Systems > William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 17 Apr '09

17 Apr '09

Someone pointed out to me this morning that there's no restriction on the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may be an expression, for example. I think that pretty much seals the deal that #2 is the correct way. I think that this is worth an ATI in the text; does anyone disagree? I volunteer to write it up/make a 3.0 ticket (hey, first ticket for the Misc WG! :-) ) if no one disagrees. On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: > Hi, > > Intel MPI (and most likely other MPICH2 derivatives) appears to use > method #2. > > Best regards. > > Alexander > > -----Original Message----- > From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > Sent: Thursday, April 16, 2009 4:19 PM > To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert > Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; > Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard > Ry; Håkon Bugge > Subject: Another MPI-2.2 attribute ambiguity? > > This is related to -- but different from -- MPI 2.2 ticket #55 > ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly > adding all the #55 CC members to this mail, plus a few others. > > I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific > behavior regarding the EXTRA_STATE arguments passed to the Fortran > keyval copy and delete functions (both the ADDRESS_KIND and deprecated > flavors). I see two choices: > > 1. pass the user's original EXTRA_STATE argument by reference to the > callbacks, or > 2. copy the user's original EXTRA_STATE into internal MPI storage and > pass *that* value by reference to the callbacks > > ==> Open MPI currently does #1. What do other implementations do? > > I raise this issue because the text does not indicate which way is > right. And I just ran across an old Sun test that assumed #2. But > our internal copy of the Intel MPI tests assume #1 (to be fair: I have > no idea if the Intel tests originally assumed #2 and we changed them > to #1 over time). Indeed, #2 is actually in-line with the philosophy > of storing attribute values in internal MPI storage. E.g.: > > INTEGER foo = 4 > INTEGER bar > CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) > foo = 5 > CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) > > bar should equal 4, not 5 (right?). > > So what does that mean (or imply) about the EXTRA_STATE value passed > to the Fortran callbacks? > > -- > Jeff Squyres > Cisco Systems > > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 17 Apr '09

17 Apr '09

Hi, Intel MPI (and most likely other MPICH2 derivatives) appears to use method #2. Best regards. Alexander -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 4:19 PM To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard Ry; Håkon Bugge Subject: Another MPI-2.2 attribute ambiguity? This is related to -- but different from -- MPI 2.2 ticket #55 ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly adding all the #55 CC members to this mail, plus a few others. I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific behavior regarding the EXTRA_STATE arguments passed to the Fortran keyval copy and delete functions (both the ADDRESS_KIND and deprecated flavors). I see two choices: 1. pass the user's original EXTRA_STATE argument by reference to the callbacks, or 2. copy the user's original EXTRA_STATE into internal MPI storage and pass *that* value by reference to the callbacks ==> Open MPI currently does #1. What do other implementations do? I raise this issue because the text does not indicate which way is right. And I just ran across an old Sun test that assumed #2. But our internal copy of the Intel MPI tests assume #1 (to be fair: I have no idea if the Intel tests originally assumed #2 and we changed them to #1 over time). Indeed, #2 is actually in-line with the philosophy of storing attribute values in internal MPI storage. E.g.: INTEGER foo = 4 INTEGER bar CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) foo = 5 CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) bar should equal 4, not 5 (right?). So what does that mean (or imply) about the EXTRA_STATE value passed to the Fortran callbacks? -- Jeff Squyres Cisco Systems --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 16 Apr '09

16 Apr '09

Yes, I was focused on ATTR and not the extra_state aspect. It looks like we did modify the Intel test suite in this case. We basically included our own method to count the number of times the callback was called and did not use the EXTRA_STATE "feature" as a method to do this. So, you are correct that the Intel test suite (unmodified) will fail with approach #2. Apparently, our founding fathers here on HP-MPI believed very strongly that the Intel test was bogus and we were doing the right thing. Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 4:14 PM To: Solt, David George Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge Subject: Re: Another MPI-2.2 attribute ambiguity? What about when you call COMM_DUP? That's when the COPY callback will be invoked. In my copy of MPI_Keyval1_f.F, in COPY_FUNCTION1, it does the following: EXTRA_STATE = EXTRA_STATE + 1 And then later in the application, it checks the value of EXTRA1 to see if it was incremented to 3 (by calling COPY_FUNCTION1 3 times). Hence, it's assuming that EXTRA_STATE in COPY_FUNCTION1 is really a reference to a global variable -- not a pointer to internal MPI state. Does yours not do that? On Apr 16, 2009, at 5:09 PM, Solt, David George wrote: > We do have an internal copy of the Intel MPI tests. We also down > loaded a more recent copy for comparison. In both cases I do not > see code in MPI_KEYVAL1_F that would differentiate between the two > interpretations. All of the tests seem to follow the following > general pattern: > > INTEGER ATTR = MPIKEYVAL_ME > .... > CALL MPI_COMM_SET_ATTR(comm, keyval, ATTR, ierr) .... > <ATTR is not changed> > .... > CALL MPI_COMM_GET_ATTR(comm, keyval, ATTR, flag, ierr) > > <test flag or test if ATTR is MPIKEYVAL_ME> > > Dave > > -----Original Message----- > From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > Sent: Thursday, April 16, 2009 9:35 AM > To: Solt, David George > Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert > Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; > Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge > Subject: Re: Another MPI-2.2 attribute ambiguity? > > On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > > > HP-MPI does #2. > > > > What if the address of the variable originally passed in is no > longer > > in scope when the corresponding comm_get_attr call is made? > > > > Ya, that can be a problem. > > Do you have an internal copy of the Intel MPI tests? What does > MPI_KEYVAL1_F do? Ours checks that the value of a global variable has > been changed by the callbacks. > > I think that's why we coded it up in Open MPI this way, but I'm not > sure (that was a long time ago). > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 16 Apr '09

16 Apr '09

What about when you call COMM_DUP? That's when the COPY callback will be invoked. In my copy of MPI_Keyval1_f.F, in COPY_FUNCTION1, it does the following: EXTRA_STATE = EXTRA_STATE + 1 And then later in the application, it checks the value of EXTRA1 to see if it was incremented to 3 (by calling COPY_FUNCTION1 3 times). Hence, it's assuming that EXTRA_STATE in COPY_FUNCTION1 is really a reference to a global variable -- not a pointer to internal MPI state. Does yours not do that? On Apr 16, 2009, at 5:09 PM, Solt, David George wrote: > We do have an internal copy of the Intel MPI tests. We also down > loaded a more recent copy for comparison. In both cases I do not > see code in MPI_KEYVAL1_F that would differentiate between the two > interpretations. All of the tests seem to follow the following > general pattern: > > INTEGER ATTR = MPIKEYVAL_ME > .... > CALL MPI_COMM_SET_ATTR(comm, keyval, ATTR, ierr) > .... > <ATTR is not changed> > .... > CALL MPI_COMM_GET_ATTR(comm, keyval, ATTR, flag, ierr) > > <test flag or test if ATTR is MPIKEYVAL_ME> > > Dave > > -----Original Message----- > From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > Sent: Thursday, April 16, 2009 9:35 AM > To: Solt, David George > Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert > Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; > Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge > Subject: Re: Another MPI-2.2 attribute ambiguity? > > On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > > > HP-MPI does #2. > > > > What if the address of the variable originally passed in is no > longer > > in scope when the corresponding comm_get_attr call is made? > > > > Ya, that can be a problem. > > Do you have an internal copy of the Intel MPI tests? What does > MPI_KEYVAL1_F do? Ours checks that the value of a global variable has > been changed by the callbacks. > > I think that's why we coded it up in Open MPI this way, but I'm not > sure (that was a long time ago). > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 16 Apr '09

16 Apr '09

We do have an internal copy of the Intel MPI tests. We also down loaded a more recent copy for comparison. In both cases I do not see code in MPI_KEYVAL1_F that would differentiate between the two interpretations. All of the tests seem to follow the following general pattern: INTEGER ATTR = MPIKEYVAL_ME .... CALL MPI_COMM_SET_ATTR(comm, keyval, ATTR, ierr) .... <ATTR is not changed> .... CALL MPI_COMM_GET_ATTR(comm, keyval, ATTR, flag, ierr) <test flag or test if ATTR is MPIKEYVAL_ME> Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 9:35 AM To: Solt, David George Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge Subject: Re: Another MPI-2.2 attribute ambiguity? On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > HP-MPI does #2. > > What if the address of the variable originally passed in is no longer > in scope when the corresponding comm_get_attr call is made? > Ya, that can be a problem. Do you have an internal copy of the Intel MPI tests? What does MPI_KEYVAL1_F do? Ours checks that the value of a global variable has been changed by the callbacks. I think that's why we coded it up in Open MPI this way, but I'm not sure (that was a long time ago). -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 16 Apr '09

16 Apr '09

Hi, NEC MPI uses #1 approach (such as for mpi_register_datarep and mpi_grequest_start). I assume that #2 is more in the Fortran spirit. Hubert Jeff Squyres wrote: > This is related to -- but different from -- MPI 2.2 ticket #55 > ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly > adding all the #55 CC members to this mail, plus a few others. > > I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific > behavior regarding the EXTRA_STATE arguments passed to the Fortran > keyval copy and delete functions (both the ADDRESS_KIND and deprecated > flavors). I see two choices: > > 1. pass the user's original EXTRA_STATE argument by reference to the > callbacks, or > 2. copy the user's original EXTRA_STATE into internal MPI storage and > pass *that* value by reference to the callbacks > > ==> Open MPI currently does #1. What do other implementations do? > > I raise this issue because the text does not indicate which way is > right. And I just ran across an old Sun test that assumed #2. But > our internal copy of the Intel MPI tests assume #1 (to be fair: I have > no idea if the Intel tests originally assumed #2 and we changed them > to #1 over time). Indeed, #2 is actually in-line with the philosophy > of storing attribute values in internal MPI storage. E.g.: > > INTEGER foo = 4 > INTEGER bar > CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) > foo = 5 > CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) > > bar should equal 4, not 5 (right?). > > So what does that mean (or imply) about the EXTRA_STATE value passed > to the Fortran callbacks? > > --Jeff Squyres > Cisco Systems > *

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 16 Apr '09

16 Apr '09

On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > HP-MPI does #2. > > What if the address of the variable originally passed in is no > longer in scope when the corresponding comm_get_attr call is made? > Ya, that can be a problem. Do you have an internal copy of the Intel MPI tests? What does MPI_KEYVAL1_F do? Ours checks that the value of a global variable has been changed by the callbacks. I think that's why we coded it up in Open MPI this way, but I'm not sure (that was a long time ago). -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 16 Apr '09

16 Apr '09

HP-MPI does #2. What if the address of the variable originally passed in is no longer in scope when the corresponding comm_get_attr call is made? Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 9:19 AM To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Solt, David George; Hans Westgaard Ry; Håkon Bugge Subject: Another MPI-2.2 attribute ambiguity? This is related to -- but different from -- MPI 2.2 ticket #55 ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly adding all the #55 CC members to this mail, plus a few others. I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific behavior regarding the EXTRA_STATE arguments passed to the Fortran keyval copy and delete functions (both the ADDRESS_KIND and deprecated flavors). I see two choices: 1. pass the user's original EXTRA_STATE argument by reference to the callbacks, or 2. copy the user's original EXTRA_STATE into internal MPI storage and pass *that* value by reference to the callbacks ==> Open MPI currently does #1. What do other implementations do? I raise this issue because the text does not indicate which way is right. And I just ran across an old Sun test that assumed #2. But our internal copy of the Intel MPI tests assume #1 (to be fair: I have no idea if the Intel tests originally assumed #2 and we changed them to #1 over time). Indeed, #2 is actually in-line with the philosophy of storing attribute values in internal MPI storage. E.g.: INTEGER foo = 4 INTEGER bar CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) foo = 5 CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) bar should equal 4, not 5 (right?). So what does that mean (or imply) about the EXTRA_STATE value passed to the Fortran callbacks? -- Jeff Squyres Cisco Systems

1 0