- Mpi-21 - mailman3.cels.anl.gov

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

On Thu, 7 Feb 2008 12:22:27 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >On Feb 7, 2008, at 11:28 AM, Rolf Rabenseifner wrote: > >> MPI 2.0 Sect.4.12.7 Attributes, page 58 lines 14-16 read: >> >> When an integer valued attribute is accessed from C or C++, >> then MPI xxx get attr will return the address of (a pointer to) >> the integer valued attribute. >> >> but should read: >> >> When an integer valued attribute is accessed from C or C++, >> then MPI xxx get attr will return the address of (a pointer to) >> the integer valued attribute; the address is only valid as long >> the attribute is not changed or the object on which the attribute >> is cached is not freed. > >Shouldn't the "or" in the last phrase be "and"? Yes, "and" is what I wanted to say. >> Additional proposal (B): Add at the end of the previous text: >> The application must not change this integer valued attribute >> at the returned address. > >I had to think about this quite a bit before I "got it" -- you're >saying that when an integer-valued attribute is set (from fortran), >the MPI implementation must be caching the value internally and then >returning a pointer to that internally cached value. Hence, the >address is only valid as long as the MPI object is valid. > >However, I'm not sure about the requirement of not changing the value >(for integer-valued attributes). If you MPI_xxx_get_attr from C and >change the value, it'll be changed for any subsequent MPI_xxx_get_attr >calls from C or Fortran. However, if you MPI_xxx_get_attr from >Fortran and change the value, the next call to MPI_xxx_get_attr will >have the original value. > >Are you just trying to avoid this disparity? Normally, MPI never gives the application the right to change anything in a opaque object without calling an MPI routine. C-routine MPI_xxx_get_attr is called with a handle to a opaque object that has stored a Fortran integer-valued attribute. IF we allow, that MPI_xxx_get_attr returns a pointer to foo and foo contains the value of such fortran-integer-attribute, AND IF we allow that a subsequent same call to MPI_xxx_get_attr returns the same pointer to same foo, AND IF we allow that the application may change the value of foo, THEN I would report: foo is part of the opaque object and we allowed that the application has changed the value without calling MPI_xxx_set_attr. If we do not want this, then there are two solutions: - restrictive: to forbid changing the value from C directly; - memory wasting: producing always a new foo in each call to MPI_xxx_get_attr. Restrictive solution is also faster! Nevertheless - ugly ;-) Kind regards Rolf >> Comment: >> I know, that this proposal has limited value in multithreaded >> execution when one thread tries to get an attribute and another >> thread is modifying it, but this must be handled by locks on >> application level. >> >> Proposal A requires that for each call to C routine MPI_xxx_get_attr() >> with a integer-valued attribute argument, a new location is >> produced in the object where the attribute is copied and from >> which the address is returned. >> >> Proposal A+B allows that the address of the originally stored >> integer is returned by MPI_xxx_get_attr(). >> >> Therefore A+B requires smallest implementation effort. >> >> Is this a good solution? >> >> Best regards >> Rolf >> >> On Thu, 07 Feb 2008 10:49:12 -0500 >> Terry Dontje <Terry.Dontje_at_[hidden]> wrote: >>> Sorry I didn't send this out sooner but in reading the discussion for >>> the errata item "Interlaguage use of Attributes" I think the below >>> proposal has a potential hole that never was resolved in the mail >>> discussion in: >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >>> >>> The specific hole pointed out by Nick Nevin in the following >>> paragraph >>> from the email discussion: >>> >>> This might work for predefined attributes where the address can >>> point to the integer value in static storage, but won't work for >>> attributes set by the user in Fortran code. If you store a pointer >>> to the integer as the attribute it may point to a temporary which >>> might no longer exist when you try and access it later. >>> >>> >>> So I think relying on the address passed in for the attribute as >>> opposed >>> to the value could cause some >>> issues with Fortran. >>> >>> --td >>> Jeff Squyres wrote: >>>> Per >>>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ >>>> , >>>> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >>>> Attributes in C and Fortran)". I believe that this errata item >>>> supersedes the errata item "Interlanguage use of Attributes". >>>> >>>> See the mail discussing: >>>> >>>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >>>> >>>> >>>> Proposal: >>>> >>>> Change MPI-2:4.12, p58:36 from: >>>> IF (val.NE.5) THEN CALL ERROR >>>> to >>>> IF (val.NE.address_of_i) THEN CALL ERROR >>>> >>>> Rationale: >>>> >>>> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >>>> set by C, retrieving it in Fortran will obtain the address of the >>>> attribute. >>>> >>>> See the mails for more discussion, including an exhaustive list of >>>> what happens for each of the 9 possibilities of setting and getting >>>> attribute values between the different languages. >>>> >>> >>> _______________________________________________ >>> mpi-21 mailing list >>> mpi-21_at_[hidden] >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

Terry and I further noticed that there appears to be another minor problem in example 4.13. So here's an addendum to the proposal: MPI-2:4.12.7 p59 line 1 reads: int *p But should read MPI_Aint *p Rationale: The value that is set from fortran is an INTEGER(kind=MPI_ADDRESS_KIND). Hence, to dereference it properly, the corresponding C pointer type needs to be an (MPI_Aint*), not (int*). On Feb 7, 2008, at 12:04 PM, Terry Dontje wrote: > After talking with Jeff and reading the spec further I retract my > concern because the spec does explicitly cover my concern in the > verbage > above example 4.13. > > --td > > Terry Dontje wrote: >> Sorry I didn't send this out sooner but in reading the discussion for >> the errata item "Interlaguage use of Attributes" I think the below >> proposal has a potential hole that never was resolved in the mail >> discussion in: >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >> >> >> The specific hole pointed out by Nick Nevin in the following >> paragraph >> from the email discussion: >> >> This might work for predefined attributes where the address can >> point to the integer value in static storage, but won't work for >> attributes set by the user in Fortran code. If you store a pointer >> to the integer as the attribute it may point to a temporary which >> might no longer exist when you try and access it later. >> >> >> So I think relying on the address passed in for the attribute as >> opposed to the value could cause some >> issues with Fortran. >> >> --td >> Jeff Squyres wrote: >>> Per >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ >>> , >>> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >>> Attributes in C and Fortran)". I believe that this errata item >>> supersedes the errata item "Interlanguage use of Attributes". >>> >>> See the mail discussing: >>> >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >>> >>> >>> Proposal: >>> >>> Change MPI-2:4.12, p58:36 from: >>> IF (val.NE.5) THEN CALL ERROR >>> to >>> IF (val.NE.address_of_i) THEN CALL ERROR >>> >>> Rationale: >>> >>> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >>> set by C, retrieving it in Fortran will obtain the address of the >>> attribute. >>> >>> See the mails for more discussion, including an exhaustive list of >>> what happens for each of the 9 possibilities of setting and getting >>> attribute values between the different languages. >>> >> >> > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

On Feb 7, 2008, at 11:28 AM, Rolf Rabenseifner wrote: > MPI 2.0 Sect.4.12.7 Attributes, page 58 lines 14-16 read: > > When an integer valued attribute is accessed from C or C++, > then MPI xxx get attr will return the address of (a pointer to) > the integer valued attribute. > > but should read: > > When an integer valued attribute is accessed from C or C++, > then MPI xxx get attr will return the address of (a pointer to) > the integer valued attribute; the address is only valid as long > the attribute is not changed or the object on which the attribute > is cached is not freed. Shouldn't the "or" in the last phrase be "and"? > Additional proposal (B): Add at the end of the previous text: > The application must not change this integer valued attribute > at the returned address. I had to think about this quite a bit before I "got it" -- you're saying that when an integer-valued attribute is set (from fortran), the MPI implementation must be caching the value internally and then returning a pointer to that internally cached value. Hence, the address is only valid as long as the MPI object is valid. However, I'm not sure about the requirement of not changing the value (for integer-valued attributes). If you MPI_xxx_get_attr from C and change the value, it'll be changed for any subsequent MPI_xxx_get_attr calls from C or Fortran. However, if you MPI_xxx_get_attr from Fortran and change the value, the next call to MPI_xxx_get_attr will have the original value. Are you just trying to avoid this disparity? > Comment: > I know, that this proposal has limited value in multithreaded > execution when one thread tries to get an attribute and another > thread is modifying it, but this must be handled by locks on > application level. > > Proposal A requires that for each call to C routine MPI_xxx_get_attr() > with a integer-valued attribute argument, a new location is > produced in the object where the attribute is copied and from > which the address is returned. > > Proposal A+B allows that the address of the originally stored > integer is returned by MPI_xxx_get_attr(). > > Therefore A+B requires smallest implementation effort. > > Is this a good solution? > > Best regards > Rolf > > On Thu, 07 Feb 2008 10:49:12 -0500 > Terry Dontje <Terry.Dontje_at_[hidden]> wrote: >> Sorry I didn't send this out sooner but in reading the discussion for >> the errata item "Interlaguage use of Attributes" I think the below >> proposal has a potential hole that never was resolved in the mail >> discussion in: >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >> >> The specific hole pointed out by Nick Nevin in the following >> paragraph >> from the email discussion: >> >> This might work for predefined attributes where the address can >> point to the integer value in static storage, but won't work for >> attributes set by the user in Fortran code. If you store a pointer >> to the integer as the attribute it may point to a temporary which >> might no longer exist when you try and access it later. >> >> >> So I think relying on the address passed in for the attribute as >> opposed >> to the value could cause some >> issues with Fortran. >> >> --td >> Jeff Squyres wrote: >>> Per >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ >>> , >>> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >>> Attributes in C and Fortran)". I believe that this errata item >>> supersedes the errata item "Interlanguage use of Attributes". >>> >>> See the mail discussing: >>> >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >>> >>> >>> Proposal: >>> >>> Change MPI-2:4.12, p58:36 from: >>> IF (val.NE.5) THEN CALL ERROR >>> to >>> IF (val.NE.address_of_i) THEN CALL ERROR >>> >>> Rationale: >>> >>> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >>> set by C, retrieving it in Fortran will obtain the address of the >>> attribute. >>> >>> See the mails for more discussion, including an exhaustive list of >>> what happens for each of the 9 possibilities of setting and getting >>> attribute values between the different languages. >>> >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

After talking with Jeff and reading the spec further I retract my concern because the spec does explicitly cover my concern in the verbage above example 4.13. --td Terry Dontje wrote: > Sorry I didn't send this out sooner but in reading the discussion for > the errata item "Interlaguage use of Attributes" I think the below > proposal has a potential hole that never was resolved in the mail > discussion in: > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… > > > The specific hole pointed out by Nick Nevin in the following paragraph > from the email discussion: > > This might work for predefined attributes where the address can > point to the integer value in static storage, but won't work for > attributes set by the user in Fortran code. If you store a pointer > to the integer as the attribute it may point to a temporary which > might no longer exist when you try and access it later. > > > So I think relying on the address passed in for the attribute as > opposed to the value could cause some > issues with Fortran. > > --td > Jeff Squyres wrote: >> Per >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/, >> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >> Attributes in C and Fortran)". I believe that this errata item >> supersedes the errata item "Interlanguage use of Attributes". >> >> See the mail discussing: >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >> >> >> Proposal: >> >> Change MPI-2:4.12, p58:36 from: >> IF (val.NE.5) THEN CALL ERROR >> to >> IF (val.NE.address_of_i) THEN CALL ERROR >> >> Rationale: >> >> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >> set by C, retrieving it in Fortran will obtain the address of the >> attribute. >> >> See the mails for more discussion, including an exhaustive list of >> what happens for each of the 9 possibilities of setting and getting >> attribute values between the different languages. >> > >

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

Yes, we should make the following proposal (A) MPI 2.0 Sect.4.12.7 Attributes, page 58 lines 14-16 read: When an integer valued attribute is accessed from C or C++, then MPI xxx get attr will return the address of (a pointer to) the integer valued attribute. but should read: When an integer valued attribute is accessed from C or C++, then MPI xxx get attr will return the address of (a pointer to) the integer valued attribute; the address is only valid as long the attribute is not changed or the object on which the attribute is cached is not freed. Additional proposal (B): Add at the end of the previous text: The application must not change this integer valued attribute at the returned address. Comment: I know, that this proposal has limited value in multithreaded execution when one thread tries to get an attribute and another thread is modifying it, but this must be handled by locks on application level. Proposal A requires that for each call to C routine MPI_xxx_get_attr() with a integer-valued attribute argument, a new location is produced in the object where the attribute is copied and from which the address is returned. Proposal A+B allows that the address of the originally stored integer is returned by MPI_xxx_get_attr(). Therefore A+B requires smallest implementation effort. Is this a good solution? Best regards Rolf On Thu, 07 Feb 2008 10:49:12 -0500 Terry Dontje <Terry.Dontje_at_[hidden]> wrote: >Sorry I didn't send this out sooner but in reading the discussion for >the errata item "Interlaguage use of Attributes" I think the below >proposal has a potential hole that never was resolved in the mail >discussion in: >http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… > >The specific hole pointed out by Nick Nevin in the following paragraph >from the email discussion: > >This might work for predefined attributes where the address can >point to the integer value in static storage, but won't work for >attributes set by the user in Fortran code. If you store a pointer >to the integer as the attribute it may point to a temporary which >might no longer exist when you try and access it later. > > >So I think relying on the address passed in for the attribute as opposed >to the value could cause some >issues with Fortran. > >--td >Jeff Squyres wrote: >> Per >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/, >> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >> Attributes in C and Fortran)". I believe that this errata item >> supersedes the errata item "Interlanguage use of Attributes". >> >> See the mail discussing: >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >> >> >> Proposal: >> >> Change MPI-2:4.12, p58:36 from: >> IF (val.NE.5) THEN CALL ERROR >> to >> IF (val.NE.address_of_i) THEN CALL ERROR >> >> Rationale: >> >> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >> set by C, retrieving it in Fortran will obtain the address of the >> attribute. >> >> See the mails for more discussion, including an exhaustive list of >> what happens for each of the 9 possibilities of setting and getting >> attribute values between the different languages. >> > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

Sorry I didn't send this out sooner but in reading the discussion for the errata item "Interlaguage use of Attributes" I think the below proposal has a potential hole that never was resolved in the mail discussion in: http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… The specific hole pointed out by Nick Nevin in the following paragraph from the email discussion: This might work for predefined attributes where the address can point to the integer value in static storage, but won't work for attributes set by the user in Fortran code. If you store a pointer to the integer as the attribute it may point to a temporary which might no longer exist when you try and access it later. So I think relying on the address passed in for the attribute as opposed to the value could cause some issues with Fortran. --td Jeff Squyres wrote: > Per > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/, > the errata item entitled "Error in Example 4.13 in MPI-2 (Use of > Attributes in C and Fortran)". I believe that this errata item > supersedes the errata item "Interlanguage use of Attributes". > > See the mail discussing: > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… > > > Proposal: > > Change MPI-2:4.12, p58:36 from: > IF (val.NE.5) THEN CALL ERROR > to > IF (val.NE.address_of_i) THEN CALL ERROR > > Rationale: > > MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is > set by C, retrieving it in Fortran will obtain the address of the > attribute. > > See the mails for more discussion, including an exhaustive list of > what happens for each of the 9 possibilities of setting and getting > attribute values between the different languages. >

1 0

Ballot 4 - all proposal now on the web
by unknown＠example.com 07 Feb '08

07 Feb '08

Hi all interested in MPI 2.1! all proposals are now on the Web: http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… Please, check whether I've done something wrong. Although I've written the details of some of these proposals, I try to be the moderator of the discussion. In some cases, when I saw that several options are possible, and none of these seemed to me technically obvious or perfect, I've put all these options on the web page to allow that the MPI Forum can make those decisions at the March meeting. Please check, whether I've done something wrong or whether I have to add an additional alternative proposal (in this case, please write the proposal with all necessary details (as text) that I can make a cut&paste to the web page plus additional HTML formatting). Please check for the RED flag Ballot 4 topics and help that the missing proposals are written. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-21] Ballot 4 - Re: [mpi-forum] MPI_Startall / MPI_Waitall / MPI_Testall clarification?
by unknown＠example.com 06 Feb '08

06 Feb '08

One comment - the clarification should not mention the progress engine. We have a general requirement in the standard that MPI make progress and there is debate about what that requires. (Must there be an asynchronous progress engine). In general we do not attach a progress semantic to specific MPI calls. Even for something like MPI_Wait, there is no statement that MPI_Wait drives a progress engine. Only that MPI_Wait returns when the request is complete. It is not a part of MPI_Wait semantic to say that the MPI_Wait call runs a progress engine or does not run one. I assume almost every MPI implementation does run its progress engine within a blocked MPI_Wait and probably no MPI gives the progress engine a time limited kick in a MPI_Comm_rank call. Either way it is an impementation decision, not part of the standard. (Of course something like MPI_Comm_rank could not block but if an MPI implementor wanted to run the progress engine for a max of 50 microseconds on every single MPI call, the standard would not forbid it.) Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 02/06/2008 12:37:20 PM: > Dries, > > Sounds fine. Nobody raised problems with this clarification up to now. > > Please can you write a full proposal of exactly what to change/add/... > > I would put it to MPI 2.1 Ballot 4. > > Best regards > Rolf > > On Mon, 4 Feb 2008 16:24:03 +0100 > Dries Kimpe <Dries.Kimpe_at_[hidden]> wrote: > >>From the standard: (same for MPI_Startall, MPI_Testall) > > > >The error-free execution of MPI_WAITALL(count, array_of_requests, > >array_of_statuses) has the same effect as the execution of > >MPI_WAIT(&array_of_request[i], &array_of_statuses[i]), for i=0 ,..., > >count-1, in some arbitrary order. > > > >What about count==0? > > > >1) Is it allowed? > > > >2) If it is allowed, should a valid pointer be provided as the > >array_of_requests argument? > > > >Looking at mpich-1.0.6p1, I see the following: > > > > > >Function Allows count==0 Allows bufptr=0 when count==0 > >MPI_Testall Y Y > >MPI_Testsome Y Y > >MPI_Testany Y Y > >MPI_Waitsome Y Y > >MPI_Waitall Y Y > >MPI_Waitany Y Y > >MPI_Startall Y N > > > >For MPI_Startall: > > > >Fatal error in MPI_Startall: Invalid argument, error stack: > >MPI_Startall(147): MPI_Startall(count=0, req_array=(nil)) failed > >MPI_Startall(80).: Null pointer in parameter array_of_requests[0]0: > Return code = 0, signaled with Interrupt > > > >Considering the other ...all functions allow count==0 and ignore the array > >in this case, the behaviour of MPI_Startall is probably just an oversight > >in mpich. > > > >For some reason, OpenMPI has exactly the same behavior; > >MPI_Startall doesn't allow req_array==0 even if count==0 > >(MPI_ERR_REQUEST is raised/returned) > > > >There is also an issue: progress. For example, in OpenMPI, calling > >MPI_Testall with count==0 doesn't do anything at all. More specific, it > >doesn't call the progress engine. > > > >Mpich however, does call the progress engine, even if count==0. > >(On the other hand, MPI_Waitall does NOT try to make progress if count==0) > > > >I propose to clarify where needed, and explicitly allow count==0; > >Also, if count==0, then 0 should be accepted as pointer for the request > >array, and no guarantee of progress should be made. > > > >If count==0, the returned error code should be MPI_SUCCESS (unless of > >course, an asynchronous error is detected). > > > >It would suffice to add "When count is zero, this call has no effect." > >(For MPI_Startall, MPI_Testall, MPI_Waitall this can be right after the > >text quoted on top of this message; For MPI_Waitany, MPI_Testany, > >MPI_Waitsome, MPI_Testsome, the addition should be at the end of the > >paragraph.) > > > > > > Greetings, > > Dries > > > >_______________________________________________ > >mpi-forum mailing list > >mpi-forum_at_[hidden] > >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-forum > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Ballot 4 - Re: [mpi-forum] MPI_Startall / MPI_Waitall / MPI_Testall clarification?
by unknown＠example.com 06 Feb '08

06 Feb '08

Dries, Sounds fine. Nobody raised problems with this clarification up to now. Please can you write a full proposal of exactly what to change/add/... I would put it to MPI 2.1 Ballot 4. Best regards Rolf On Mon, 4 Feb 2008 16:24:03 +0100 Dries Kimpe <Dries.Kimpe_at_[hidden]> wrote: >>From the standard: (same for MPI_Startall, MPI_Testall) > >The error-free execution of MPI_WAITALL(count, array_of_requests, >array_of_statuses) has the same effect as the execution of >MPI_WAIT(&array_of_request[i], &array_of_statuses[i]), for i=0 ,..., >count-1, in some arbitrary order. > >What about count==0? > >1) Is it allowed? > >2) If it is allowed, should a valid pointer be provided as the >array_of_requests argument? > >Looking at mpich-1.0.6p1, I see the following: > > >Function Allows count==0 Allows bufptr=0 when count==0 >MPI_Testall Y Y >MPI_Testsome Y Y >MPI_Testany Y Y >MPI_Waitsome Y Y >MPI_Waitall Y Y >MPI_Waitany Y Y >MPI_Startall Y N > >For MPI_Startall: > >Fatal error in MPI_Startall: Invalid argument, error stack: >MPI_Startall(147): MPI_Startall(count=0, req_array=(nil)) failed >MPI_Startall(80).: Null pointer in parameter array_of_requests[0]0:Return code = 0, signaled with Interrupt > >Considering the other ...all functions allow count==0 and ignore the array >in this case, the behaviour of MPI_Startall is probably just an oversight >in mpich. > >For some reason, OpenMPI has exactly the same behavior; >MPI_Startall doesn't allow req_array==0 even if count==0 >(MPI_ERR_REQUEST is raised/returned) > >There is also an issue: progress. For example, in OpenMPI, calling >MPI_Testall with count==0 doesn't do anything at all. More specific, it >doesn't call the progress engine. > >Mpich however, does call the progress engine, even if count==0. >(On the other hand, MPI_Waitall does NOT try to make progress if count==0) > >I propose to clarify where needed, and explicitly allow count==0; >Also, if count==0, then 0 should be accepted as pointer for the request >array, and no guarantee of progress should be made. > >If count==0, the returned error code should be MPI_SUCCESS (unless of >course, an asynchronous error is detected). > >It would suffice to add "When count is zero, this call has no effect." >(For MPI_Startall, MPI_Testall, MPI_Waitall this can be right after the >text quoted on top of this message; For MPI_Waitany, MPI_Testany, >MPI_Waitsome, MPI_Testsome, the addition should be at the end of the >paragraph.) > > > Greetings, > Dries > >_______________________________________________ >mpi-forum mailing list >mpi-forum_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-forum Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-21] Two MPI I/O questions
by unknown＠example.com 06 Feb '08

06 Feb '08

I talked with Len and we believe topic one has already been addressed previously and the second topic does not need to be clarified. --td Rajeev Thakur wrote: > I don't think any clarification is needed for the second topic. > > Rajeev > > >> -----Original Message----- >> From: Rolf Rabenseifner [mailto:rabenseifner_at_[hidden]] >> Sent: Tuesday, January 29, 2008 6:22 AM >> To: mpi-21_at_[hidden] >> Cc: Leonard F. Wisniewski; Rajeev Thakur >> Subject: Re: Two MPI I/O questions >> >> Mainly to Leonard Wisniewski and Rajeev Thakur >> who have contributed to this mail-discussion thread. >> >> This is a follow up to: >> Shared File Pointers >> in >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/index.html >> with mail discussion in >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/discuss/sharedfile/ >> >> and here only to the second topic in the mails. >> (The first topic is handled in the thread >> "MPI C++ Constants conflict with stdio") >> >> _________________________________________ >> >> When I understand correctly, then a clarification is not needed >> in the MPI standard. >> >> If somebody wants a clarification to be included into the standard >> and therefore in Ballot 4, please send me your wording >> with the page and line references included. >> >> If all agree, that no clarification is needed, then I would finish >> this discussion-thread. >> >> Best regards >> Rolf >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> >> >> > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >

1 0