- mpi-comments - mailman3.cels.anl.gov

Non blocking receive of unknown size
by Alain Miniussi 13 Sep '18

13 Sep '18

Hi, (text location provided w.r.t MPI 3.1 https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf) a) In 3.2.4, page 29, there is a discussion regarding the size of the buffer and size of the actual message with an "advice to users" section stating that : "The MPI_PROBE function described in Section 3.8 can be used to receive messages of unknown length." b) There is no such discussion in 3.7.2 so one could assume (maybe too optimistically) that the same advice applies w.r.t. MPI_Iprobe. c) In 3.8.1. page 66 line 9 "The MPI implementation of MPI_PROBE and MPI_IPROBE needs to guarantee progress: [calling those functions, msg should arrive eventually if send and not intercepted]. d) The "Progress" note in 3.7.4, illustrated by example 3.14, seems to indicate that a synchronous send can not be blocked if a recv has been posted regardless of the completion of that receive. But I could not find anything explicitly stating that MPI_Iprobe would initiate a receive the way MPI_Irecv does. That is, a slightly modified 3.14 example: CALL MPI_COMM_RANK(comm, rank, ierr) IF (RANK.EQ.0) THEN CALL MPI_SSEND(a, n, MPI_REAL, 1, 0, comm, ierr) CALL MPI_SEND(b, 1, MPI_REAL, 1, 1, comm, ierr) ELSE IF (rank.EQ.1) THEN CALL MPI_IPROBE(0, 0, comm, flag, status1, ierr) CALL MPI_RECV(b, 1, MPI_REAL, 0, 1, comm, status2, ierr) ... extract size info from status1 once available .... CALL MPI_IRECV(a, n, MPI_REAL, 0, 0, comm, r, ierr) CALL MPI_WAIT(r, status, ierr) END IF could deadlock in a correct MPI implementation. If I am correct in assuming that the MPI standard ask for the MPI_Iprobe to progress, it is not required to initiate. If true, it means the the point a) above does not extend to the non blocking communications and that the MPI does not provide a way to receive messages of unknown size whithout adding more opportunities for deadlocks. Am I correct ? and if yes, does that indicate that the discussion and advice of point a could be adapted and explicitly added for the non blocking case (point b). Thanks Alain

1 0

Re: [Mpi-comments] (A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions
by Rolf Rabenseifner 11 Jun '18

11 Jun '18

> I understand the strict reading, but I don’t believe any implementation sets > inactive persistent requests to MPI_REQUEST_NULL. Yes, I completely agree. Therefore, my errata proposal addresses only users. > Do you know if any user > applications defend against this option? No, but my knowledge about applications in the world is very small. But I remember that there were positive remarks from at least one MPI-implementor that he had optimized their persistent communications. Our courses are teaching this. Therefore there may be users of persistent communications. > One reason to treat this as type-0 is that allows an immediate errata, clearing > up an ambiguity. If we treat it as a change, then (a) MPI 3.1 implementations > are thus *wrong* if they don’t set inactive persistent requests to > MPI_REQUEST_NULL and (b) the fix won’t take effect until the next MPI version > is released. I would not treat it as a change. I would treat it as an Erratum to MPI-3.0 AND 3.1, i.e., a retrospectiv correction of the text, which is done now / when it is published in the list of errata, but which is backward effective since the publication Dates of MPI-3.0 and MPI-3.1. Therefore, implementers never need to implement the wrong written text passage in versions 3.0 and 3.1. But users may have written applications according to the current wording. This means, that they wrote software to save the original correct inactive persistent request handle before it is destroyed. They may never checked that they have a "Buggy" library that never overwrote persistent request handles in subsequent calls to MPI_Wait.../Test... . They can learn from the errata text, that this complication in their Software was not needed. If we only make a typo-0 correction, then they have no opportunity to re-read the definition of MPI_Wait.../Test... for inactive persistent request handles. I'm not sure whether such obvious errata (including errata entry in the change-log) can be handled as typo-0 correction (i.e., without voting?). Best regards Rolf ----- Original Message ----- > From: "wgropp" <wgropp(a)illinois.edu> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "Comments on the MPI Standard" <mpi-comments(a)lists.mpi-forum.org> > Sent: Monday, June 11, 2018 11:52:30 AM > Subject: Re: [Mpi-comments] (A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions > I understand the strict reading, but I don’t believe any implementation sets > inactive persistent requests to MPI_REQUEST_NULL. Do you know if any user > applications defend against this option? > > One reason to treat this as type-0 is that allows an immediate errata, clearing > up an ambiguity. If we treat it as a change, then (a) MPI 3.1 implementations > are thus *wrong* if they don’t set inactive persistent requests to > MPI_REQUEST_NULL and (b) the fix won’t take effect until the next MPI version > is released. > > Bill > > William Gropp > Director and Chief Scientist, NCSA > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > >> On Jun 11, 2018, at 4:35 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> >> Hi Bill, >> >>> This looks like type-0 correction. I’m happy to treat it as such if there are >>> no objections. >> >> (A) is clearly a typo-0. >> >> (B) may be better treated with an additional entry in the erratas >> for the case that someone has implemented an application with >> a list of persistent request handles togehter with some >> calls to MPI_Waitsome until all requests are finished. >> With this Erratum, he/she now knows that he/she can keep the >> the list of request handles the whole time for the >> MPI_Startall and all MPI_Waitsome because it is now guaranteed >> that no handle will be substituted by MPI_REQUEST_NULL. >> >> Proposal: >> MPI-3.0 and MPI-3.1, Sections 3.7.3 and 3.7.5. >> As in MPI-1.x and MPI-2.x already described, inactive >> persistent request handles are also allowed in all >> MPI_WAIT... and MPI_TEST... routines and they are >> never changed to MPI_REQUEST_NULL by these routines. >> The wrong wording in MPI-3.0 and MPI-3.1 is corrected. >> >> Best regards >> Rolf >> >> >> >> ----- Original Message ----- >>> From: "wgropp" <wgropp(a)illinois.edu> >>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Comments on the MPI Standard" >>> <mpi-comments(a)lists.mpi-forum.org> >>> Sent: Monday, June 11, 2018 10:42:08 AM >>> Subject: Re: [Mpi-comments] (A) Typo and (B) mal-correction in all >>> MPI_Wait.../Test... descriptions >> >>> This looks like type-0 correction. I’m happy to treat it as such if there are >>> no objections. >>> >>> Bill >>> >>> William Gropp >>> Director and Chief Scientist, NCSA >>> Thomas M. Siebel Chair in Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> >>> >>> >>>> On Jun 8, 2018, at 10:42 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >>>> >>>> Dear all, >>>> >>>> A) Typo: >>>> >>>> My colleague Martin Bernreuther detected the following typo: >>>> >>>> MPI-3.1 Section "3.7.3 Communication Completion", "MPI_WAIT" >>>> page 53, lines 24-25 read >>>> >>>> "[...]. Any other type of request >>>> is and the request handle is set to MPI_REQUEST_NULL. [...]" >>>> >>>> but should read >>>> "[...]. Any other type of request >>>> is deallocated and the request handle is set to MPI_REQUEST_NULL. [...]" >>>> >>>> In other Locations, this sentence is correct, i.e., includes the >>>> word "deallocated", see MPI-3.1 >>>> - page 54, lines 20-21 in MPI_TEST, >>>> - page 57, lines 45-46 in MPI_WAITANY, >>>> - page 58, lines 35-36 in MPI_TESTANY, >>>> - page 59, lines 23-24 in MPI_WAITALL, >>>> - page 60, lines 25-26 in MPI_TESTALL, >>>> - page 61, lines 19-20 in MPI_WAITSOME, >>>> whereas MPI_TESTALL does not contain this sentence due >>>> to a shorter description. >>>> >>>> >>>> B) Mal-correction: >>>> >>>> The correction from MPI-2.2 to MPI-3.0 contains wrong wording for >>>> MPI_Wait/Test... in the case of inactive request handles. >>>> >>>> The correction was done to include also nonblocking collectives and IO. >>>> But the change to MPI-3.0 was not correct for inactive persistent request >>>> handles. >>>> >>>> MPI-1.1 - MPI-2.2 used the wording: >>>> >>>> "A call to MPI WAIT returns when the operation identified by request is >>>> complete. >>>> If the communication object associated with this request was created by a >>>> nonblocking send or >>>> receive call, then the object is deallocated by the call to MPI WAIT and the >>>> request handle >>>> is set to MPI REQUEST NULL. >>>> MPI WAIT is a non-local operation. >>>> The call returns, in status, [...]. >>>> One is allowed to call MPI WAIT with a null or inactive request argument. In >>>> this case >>>> the operation returns immediately with empty status." >>>> >>>> For inactive persistent request handles, the text says: >>>> - no change for the request handle, >>>> - empty status returned. >>>> >>>> >>>> MPI-3.0 and MPI-3.1 uses the following modified wording: >>>> >>>> "A call to MPI_WAIT returns when the operation identified by request is >>>> complete. >>>> If the request is an active persistent request, it is marked inactive. Any other >>>> type of request >>>> is [deallocated] and the request handle is set to MPI_REQUEST_NULL. >>>> MPI_WAIT is a non-local operation. >>>> The call returns, in status, [...]. >>>> One is allowed to call MPI_WAIT with a null or inactive request argument. In >>>> this case >>>> the operation returns immediately with empty status." >>>> >>>> For inactive persistent request handles, the text says: >>>> - that it shpould be set to MPI_REQUEST_NULL, and >>>> - empty status returned. >>>> >>>> The MPI_REQUEST_NULL was never intented and I expect that no MPI-library >>>> has implemented that wrong behavior. >>>> Note that in the case of an array of request handles, in a sequence of >>>> MPI_Wait/Test-any/some >>>> calls, it is allowed to keep the whole array untouched until all regular >>>> requests >>>> are set to MPI_REQUEST_NULL and all active persistent requests are changed to >>>> inactive. >>>> >>>> >>>> Proposal for correcting thos bug: >>>> >>>> Change all sentences >>>> >>>> "Any other type of request >>>> is deallocated and the request handle is set to MPI_REQUEST_NULL." >>>> >>>> into >>>> >>>> "Any other type of non-persistent request >>>> is deallocated and the request handle is set to MPI_REQUEST_NULL." >>>> >>>> The locations are: >>>> >>>> - page 53, lines 24-25 in MPI_WAIT (together with the typo, see (A) above) >>>> - page 54, lines 20-21 in MPI_TEST, >>>> - page 57, lines 45-46 in MPI_WAITANY, >>>> - page 58, lines 35-36 in MPI_TESTANY, >>>> - page 59, lines 23-24 in MPI_WAITALL, >>>> - page 60, lines 25-26 in MPI_TESTALL, >>>> - page 61, lines 19-20 in MPI_WAITSOME. >>>> >>>> >>>> Best regards >>>> Rolf >>>> >>>> >>>> -- >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . >>>> 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: Room 1.307) . >>>> _______________________________________________ >>>> mpi-comments mailing list >>>> mpi-comments(a)lists.mpi-forum.org >>>> https://lists.mpi-forum.org/mailman/listinfo/mpi-comments >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . >> 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: Room 1.307) . -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . 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: Room 1.307) .

1 0

Re: [Mpi-comments] (A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions
by William Gropp 11 Jun '18

11 Jun '18

I understand the strict reading, but I don’t believe any implementation sets inactive persistent requests to MPI_REQUEST_NULL. Do you know if any user applications defend against this option? One reason to treat this as type-0 is that allows an immediate errata, clearing up an ambiguity. If we treat it as a change, then (a) MPI 3.1 implementations are thus *wrong* if they don’t set inactive persistent requests to MPI_REQUEST_NULL and (b) the fix won’t take effect until the next MPI version is released. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign > On Jun 11, 2018, at 4:35 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > Hi Bill, > >> This looks like type-0 correction. I’m happy to treat it as such if there are >> no objections. > > (A) is clearly a typo-0. > > (B) may be better treated with an additional entry in the erratas > for the case that someone has implemented an application with > a list of persistent request handles togehter with some > calls to MPI_Waitsome until all requests are finished. > With this Erratum, he/she now knows that he/she can keep the > the list of request handles the whole time for the > MPI_Startall and all MPI_Waitsome because it is now guaranteed > that no handle will be substituted by MPI_REQUEST_NULL. > > Proposal: > MPI-3.0 and MPI-3.1, Sections 3.7.3 and 3.7.5. > As in MPI-1.x and MPI-2.x already described, inactive > persistent request handles are also allowed in all > MPI_WAIT... and MPI_TEST... routines and they are > never changed to MPI_REQUEST_NULL by these routines. > The wrong wording in MPI-3.0 and MPI-3.1 is corrected. > > Best regards > Rolf > > > > ----- Original Message ----- >> From: "wgropp" <wgropp(a)illinois.edu> >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Comments on the MPI Standard" <mpi-comments(a)lists.mpi-forum.org> >> Sent: Monday, June 11, 2018 10:42:08 AM >> Subject: Re: [Mpi-comments] (A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions > >> This looks like type-0 correction. I’m happy to treat it as such if there are >> no objections. >> >> Bill >> >> William Gropp >> Director and Chief Scientist, NCSA >> Thomas M. Siebel Chair in Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> >> >>> On Jun 8, 2018, at 10:42 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >>> >>> Dear all, >>> >>> A) Typo: >>> >>> My colleague Martin Bernreuther detected the following typo: >>> >>> MPI-3.1 Section "3.7.3 Communication Completion", "MPI_WAIT" >>> page 53, lines 24-25 read >>> >>> "[...]. Any other type of request >>> is and the request handle is set to MPI_REQUEST_NULL. [...]" >>> >>> but should read >>> "[...]. Any other type of request >>> is deallocated and the request handle is set to MPI_REQUEST_NULL. [...]" >>> >>> In other Locations, this sentence is correct, i.e., includes the >>> word "deallocated", see MPI-3.1 >>> - page 54, lines 20-21 in MPI_TEST, >>> - page 57, lines 45-46 in MPI_WAITANY, >>> - page 58, lines 35-36 in MPI_TESTANY, >>> - page 59, lines 23-24 in MPI_WAITALL, >>> - page 60, lines 25-26 in MPI_TESTALL, >>> - page 61, lines 19-20 in MPI_WAITSOME, >>> whereas MPI_TESTALL does not contain this sentence due >>> to a shorter description. >>> >>> >>> B) Mal-correction: >>> >>> The correction from MPI-2.2 to MPI-3.0 contains wrong wording for >>> MPI_Wait/Test... in the case of inactive request handles. >>> >>> The correction was done to include also nonblocking collectives and IO. >>> But the change to MPI-3.0 was not correct for inactive persistent request >>> handles. >>> >>> MPI-1.1 - MPI-2.2 used the wording: >>> >>> "A call to MPI WAIT returns when the operation identified by request is >>> complete. >>> If the communication object associated with this request was created by a >>> nonblocking send or >>> receive call, then the object is deallocated by the call to MPI WAIT and the >>> request handle >>> is set to MPI REQUEST NULL. >>> MPI WAIT is a non-local operation. >>> The call returns, in status, [...]. >>> One is allowed to call MPI WAIT with a null or inactive request argument. In >>> this case >>> the operation returns immediately with empty status." >>> >>> For inactive persistent request handles, the text says: >>> - no change for the request handle, >>> - empty status returned. >>> >>> >>> MPI-3.0 and MPI-3.1 uses the following modified wording: >>> >>> "A call to MPI_WAIT returns when the operation identified by request is >>> complete. >>> If the request is an active persistent request, it is marked inactive. Any other >>> type of request >>> is [deallocated] and the request handle is set to MPI_REQUEST_NULL. >>> MPI_WAIT is a non-local operation. >>> The call returns, in status, [...]. >>> One is allowed to call MPI_WAIT with a null or inactive request argument. In >>> this case >>> the operation returns immediately with empty status." >>> >>> For inactive persistent request handles, the text says: >>> - that it shpould be set to MPI_REQUEST_NULL, and >>> - empty status returned. >>> >>> The MPI_REQUEST_NULL was never intented and I expect that no MPI-library >>> has implemented that wrong behavior. >>> Note that in the case of an array of request handles, in a sequence of >>> MPI_Wait/Test-any/some >>> calls, it is allowed to keep the whole array untouched until all regular >>> requests >>> are set to MPI_REQUEST_NULL and all active persistent requests are changed to >>> inactive. >>> >>> >>> Proposal for correcting thos bug: >>> >>> Change all sentences >>> >>> "Any other type of request >>> is deallocated and the request handle is set to MPI_REQUEST_NULL." >>> >>> into >>> >>> "Any other type of non-persistent request >>> is deallocated and the request handle is set to MPI_REQUEST_NULL." >>> >>> The locations are: >>> >>> - page 53, lines 24-25 in MPI_WAIT (together with the typo, see (A) above) >>> - page 54, lines 20-21 in MPI_TEST, >>> - page 57, lines 45-46 in MPI_WAITANY, >>> - page 58, lines 35-36 in MPI_TESTANY, >>> - page 59, lines 23-24 in MPI_WAITALL, >>> - page 60, lines 25-26 in MPI_TESTALL, >>> - page 61, lines 19-20 in MPI_WAITSOME. >>> >>> >>> Best regards >>> Rolf >>> >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . >>> 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: Room 1.307) . >>> _______________________________________________ >>> mpi-comments mailing list >>> mpi-comments(a)lists.mpi-forum.org >>> https://lists.mpi-forum.org/mailman/listinfo/mpi-comments > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . > 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: Room 1.307) .

1 0

Re: [Mpi-comments] (A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions
by Rolf Rabenseifner 11 Jun '18

11 Jun '18

Hi Bill, > This looks like type-0 correction. I’m happy to treat it as such if there are > no objections. (A) is clearly a typo-0. (B) may be better treated with an additional entry in the erratas for the case that someone has implemented an application with a list of persistent request handles togehter with some calls to MPI_Waitsome until all requests are finished. With this Erratum, he/she now knows that he/she can keep the the list of request handles the whole time for the MPI_Startall and all MPI_Waitsome because it is now guaranteed that no handle will be substituted by MPI_REQUEST_NULL. Proposal: MPI-3.0 and MPI-3.1, Sections 3.7.3 and 3.7.5. As in MPI-1.x and MPI-2.x already described, inactive persistent request handles are also allowed in all MPI_WAIT... and MPI_TEST... routines and they are never changed to MPI_REQUEST_NULL by these routines. The wrong wording in MPI-3.0 and MPI-3.1 is corrected. Best regards Rolf ----- Original Message ----- > From: "wgropp" <wgropp(a)illinois.edu> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Comments on the MPI Standard" <mpi-comments(a)lists.mpi-forum.org> > Sent: Monday, June 11, 2018 10:42:08 AM > Subject: Re: [Mpi-comments] (A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions > This looks like type-0 correction. I’m happy to treat it as such if there are > no objections. > > Bill > > William Gropp > Director and Chief Scientist, NCSA > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > >> On Jun 8, 2018, at 10:42 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> >> Dear all, >> >> A) Typo: >> >> My colleague Martin Bernreuther detected the following typo: >> >> MPI-3.1 Section "3.7.3 Communication Completion", "MPI_WAIT" >> page 53, lines 24-25 read >> >> "[...]. Any other type of request >> is and the request handle is set to MPI_REQUEST_NULL. [...]" >> >> but should read >> "[...]. Any other type of request >> is deallocated and the request handle is set to MPI_REQUEST_NULL. [...]" >> >> In other Locations, this sentence is correct, i.e., includes the >> word "deallocated", see MPI-3.1 >> - page 54, lines 20-21 in MPI_TEST, >> - page 57, lines 45-46 in MPI_WAITANY, >> - page 58, lines 35-36 in MPI_TESTANY, >> - page 59, lines 23-24 in MPI_WAITALL, >> - page 60, lines 25-26 in MPI_TESTALL, >> - page 61, lines 19-20 in MPI_WAITSOME, >> whereas MPI_TESTALL does not contain this sentence due >> to a shorter description. >> >> >> B) Mal-correction: >> >> The correction from MPI-2.2 to MPI-3.0 contains wrong wording for >> MPI_Wait/Test... in the case of inactive request handles. >> >> The correction was done to include also nonblocking collectives and IO. >> But the change to MPI-3.0 was not correct for inactive persistent request >> handles. >> >> MPI-1.1 - MPI-2.2 used the wording: >> >> "A call to MPI WAIT returns when the operation identified by request is >> complete. >> If the communication object associated with this request was created by a >> nonblocking send or >> receive call, then the object is deallocated by the call to MPI WAIT and the >> request handle >> is set to MPI REQUEST NULL. >> MPI WAIT is a non-local operation. >> The call returns, in status, [...]. >> One is allowed to call MPI WAIT with a null or inactive request argument. In >> this case >> the operation returns immediately with empty status." >> >> For inactive persistent request handles, the text says: >> - no change for the request handle, >> - empty status returned. >> >> >> MPI-3.0 and MPI-3.1 uses the following modified wording: >> >> "A call to MPI_WAIT returns when the operation identified by request is >> complete. >> If the request is an active persistent request, it is marked inactive. Any other >> type of request >> is [deallocated] and the request handle is set to MPI_REQUEST_NULL. >> MPI_WAIT is a non-local operation. >> The call returns, in status, [...]. >> One is allowed to call MPI_WAIT with a null or inactive request argument. In >> this case >> the operation returns immediately with empty status." >> >> For inactive persistent request handles, the text says: >> - that it shpould be set to MPI_REQUEST_NULL, and >> - empty status returned. >> >> The MPI_REQUEST_NULL was never intented and I expect that no MPI-library >> has implemented that wrong behavior. >> Note that in the case of an array of request handles, in a sequence of >> MPI_Wait/Test-any/some >> calls, it is allowed to keep the whole array untouched until all regular >> requests >> are set to MPI_REQUEST_NULL and all active persistent requests are changed to >> inactive. >> >> >> Proposal for correcting thos bug: >> >> Change all sentences >> >> "Any other type of request >> is deallocated and the request handle is set to MPI_REQUEST_NULL." >> >> into >> >> "Any other type of non-persistent request >> is deallocated and the request handle is set to MPI_REQUEST_NULL." >> >> The locations are: >> >> - page 53, lines 24-25 in MPI_WAIT (together with the typo, see (A) above) >> - page 54, lines 20-21 in MPI_TEST, >> - page 57, lines 45-46 in MPI_WAITANY, >> - page 58, lines 35-36 in MPI_TESTANY, >> - page 59, lines 23-24 in MPI_WAITALL, >> - page 60, lines 25-26 in MPI_TESTALL, >> - page 61, lines 19-20 in MPI_WAITSOME. >> >> >> Best regards >> Rolf >> >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . >> 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: Room 1.307) . >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . 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: Room 1.307) .

1 0

Re: [Mpi-comments] (A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions
by William Gropp 11 Jun '18

11 Jun '18

This looks like type-0 correction. I’m happy to treat it as such if there are no objections. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign > On Jun 8, 2018, at 10:42 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > Dear all, > > A) Typo: > > My colleague Martin Bernreuther detected the following typo: > > MPI-3.1 Section "3.7.3 Communication Completion", "MPI_WAIT" > page 53, lines 24-25 read > > "[...]. Any other type of request > is and the request handle is set to MPI_REQUEST_NULL. [...]" > > but should read > "[...]. Any other type of request > is deallocated and the request handle is set to MPI_REQUEST_NULL. [...]" > > In other Locations, this sentence is correct, i.e., includes the > word "deallocated", see MPI-3.1 > - page 54, lines 20-21 in MPI_TEST, > - page 57, lines 45-46 in MPI_WAITANY, > - page 58, lines 35-36 in MPI_TESTANY, > - page 59, lines 23-24 in MPI_WAITALL, > - page 60, lines 25-26 in MPI_TESTALL, > - page 61, lines 19-20 in MPI_WAITSOME, > whereas MPI_TESTALL does not contain this sentence due > to a shorter description. > > > B) Mal-correction: > > The correction from MPI-2.2 to MPI-3.0 contains wrong wording for > MPI_Wait/Test... in the case of inactive request handles. > > The correction was done to include also nonblocking collectives and IO. > But the change to MPI-3.0 was not correct for inactive persistent request handles. > > MPI-1.1 - MPI-2.2 used the wording: > > "A call to MPI WAIT returns when the operation identified by request is complete. > If the communication object associated with this request was created by a nonblocking send or > receive call, then the object is deallocated by the call to MPI WAIT and the request handle > is set to MPI REQUEST NULL. > MPI WAIT is a non-local operation. > The call returns, in status, [...]. > One is allowed to call MPI WAIT with a null or inactive request argument. In this case > the operation returns immediately with empty status." > > For inactive persistent request handles, the text says: > - no change for the request handle, > - empty status returned. > > > MPI-3.0 and MPI-3.1 uses the following modified wording: > > "A call to MPI_WAIT returns when the operation identified by request is complete. > If the request is an active persistent request, it is marked inactive. Any other type of request > is [deallocated] and the request handle is set to MPI_REQUEST_NULL. > MPI_WAIT is a non-local operation. > The call returns, in status, [...]. > One is allowed to call MPI_WAIT with a null or inactive request argument. In this case > the operation returns immediately with empty status." > > For inactive persistent request handles, the text says: > - that it shpould be set to MPI_REQUEST_NULL, and > - empty status returned. > > The MPI_REQUEST_NULL was never intented and I expect that no MPI-library > has implemented that wrong behavior. > Note that in the case of an array of request handles, in a sequence of MPI_Wait/Test-any/some > calls, it is allowed to keep the whole array untouched until all regular requests > are set to MPI_REQUEST_NULL and all active persistent requests are changed to inactive. > > > Proposal for correcting thos bug: > > Change all sentences > > "Any other type of request > is deallocated and the request handle is set to MPI_REQUEST_NULL." > > into > > "Any other type of non-persistent request > is deallocated and the request handle is set to MPI_REQUEST_NULL." > > The locations are: > > - page 53, lines 24-25 in MPI_WAIT (together with the typo, see (A) above) > - page 54, lines 20-21 in MPI_TEST, > - page 57, lines 45-46 in MPI_WAITANY, > - page 58, lines 35-36 in MPI_TESTANY, > - page 59, lines 23-24 in MPI_WAITALL, > - page 60, lines 25-26 in MPI_TESTALL, > - page 61, lines 19-20 in MPI_WAITSOME. > > > Best regards > Rolf > > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . > 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: Room 1.307) . > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

1 0

(A) Typo and (B) mal-correction in all MPI_Wait.../Test... descriptions
by Rolf Rabenseifner 08 Jun '18

08 Jun '18

Dear all, A) Typo: My colleague Martin Bernreuther detected the following typo: MPI-3.1 Section "3.7.3 Communication Completion", "MPI_WAIT" page 53, lines 24-25 read "[...]. Any other type of request is and the request handle is set to MPI_REQUEST_NULL. [...]" but should read "[...]. Any other type of request is deallocated and the request handle is set to MPI_REQUEST_NULL. [...]" In other Locations, this sentence is correct, i.e., includes the word "deallocated", see MPI-3.1 - page 54, lines 20-21 in MPI_TEST, - page 57, lines 45-46 in MPI_WAITANY, - page 58, lines 35-36 in MPI_TESTANY, - page 59, lines 23-24 in MPI_WAITALL, - page 60, lines 25-26 in MPI_TESTALL, - page 61, lines 19-20 in MPI_WAITSOME, whereas MPI_TESTALL does not contain this sentence due to a shorter description. B) Mal-correction: The correction from MPI-2.2 to MPI-3.0 contains wrong wording for MPI_Wait/Test... in the case of inactive request handles. The correction was done to include also nonblocking collectives and IO. But the change to MPI-3.0 was not correct for inactive persistent request handles. MPI-1.1 - MPI-2.2 used the wording: "A call to MPI WAIT returns when the operation identified by request is complete. If the communication object associated with this request was created by a nonblocking send or receive call, then the object is deallocated by the call to MPI WAIT and the request handle is set to MPI REQUEST NULL. MPI WAIT is a non-local operation. The call returns, in status, [...]. One is allowed to call MPI WAIT with a null or inactive request argument. In this case the operation returns immediately with empty status." For inactive persistent request handles, the text says: - no change for the request handle, - empty status returned. MPI-3.0 and MPI-3.1 uses the following modified wording: "A call to MPI_WAIT returns when the operation identified by request is complete. If the request is an active persistent request, it is marked inactive. Any other type of request is [deallocated] and the request handle is set to MPI_REQUEST_NULL. MPI_WAIT is a non-local operation. The call returns, in status, [...]. One is allowed to call MPI_WAIT with a null or inactive request argument. In this case the operation returns immediately with empty status." For inactive persistent request handles, the text says: - that it shpould be set to MPI_REQUEST_NULL, and - empty status returned. The MPI_REQUEST_NULL was never intented and I expect that no MPI-library has implemented that wrong behavior. Note that in the case of an array of request handles, in a sequence of MPI_Wait/Test-any/some calls, it is allowed to keep the whole array untouched until all regular requests are set to MPI_REQUEST_NULL and all active persistent requests are changed to inactive. Proposal for correcting thos bug: Change all sentences "Any other type of request is deallocated and the request handle is set to MPI_REQUEST_NULL." into "Any other type of non-persistent request is deallocated and the request handle is set to MPI_REQUEST_NULL." The locations are: - page 53, lines 24-25 in MPI_WAIT (together with the typo, see (A) above) - page 54, lines 20-21 in MPI_TEST, - page 57, lines 45-46 in MPI_WAITANY, - page 58, lines 35-36 in MPI_TESTANY, - page 59, lines 23-24 in MPI_WAITALL, - page 60, lines 25-26 in MPI_TESTALL, - page 61, lines 19-20 in MPI_WAITSOME. Best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . 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: Room 1.307) .

1 0

Possible ambiguity on size of `array_of_indices` and `array_of_statuses`?
by Gaspar, Andrew James 08 Mar '18

08 Mar '18

Hello, These comments are on the MPI 3.1 spec[0], Section 3.7.5, pages 61 and 62 on MPI_Waitsome and MPI_Testsome. The spec makes two comments on what elements in `array_of_indices` and `array_of_statuses` are accessed: “Returns in the first outcount locations of the array array_of_indices the indices of these operations (index within the array array_of_requests; the array is indexed from zero in C and from one in Fortran)” “Returns in the first outcount locations of the array array_of_status the status for these completed operations.” As far as I can tell, the spec provides no other indication of the size of these two arrays. So, as a user, I would think that `array_of_indices` is only required to be as large as the largest possible value of `outcount`. The max value of outcount is not necessarily the same as the size of `array_of_requests`: If an array_of_requests has 10 elements, but the user knows that only 8 of the requests are active, they know that outcount must be less than or equal to 8. The reason I ask is that OpenMPI takes the liberty of treating `array_of_indices` as being the same size as `array_of_requests`[1]. It uses array_of_indices[i] as scratch space to store the completion of array_of_requests[i]. Is the spec ambiguous here, or is OpenMPI in violation of the spec? Or am I missing an explicit definition of the required size of these arrays? Thank you very much! [0] http://mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf [1] https://github.com/open-mpi/ompi/blob/master/ompi/request/req_wait.c#L422 Andrew Gaspar CCS-7 – Applied Computer Science 505-664-0676 / agaspar(a)lanl.gov

1 0

MPI_Comm_spawn_multiple: parameter description and Fortran bindings
by Gilles Gouaillardet 06 Feb '18

06 Feb '18

Dear MPI Forum, The description of the 'array_of_commands` parameter passed to 'MPI_Comm_spawn_multiple()' is not crystal clear IMHO. The standard simply states MPI_COMM_SPAWN_MULTIPLE(count, array_of_commands, ...) IN count number of commands (positive integer, significant to MPI only at root | see advice to users) IN array_of_commands programs to be executed (array of strings, significant only at root) Advice to users. The argument count is interpreted by MPI only at the root, as is array_of_argv. Since the leading dimension of array_of_argv is count, a non-positive value of count at a non-root node could theoretically cause a runtime bounds check error, even though array_of_argv should be ignored by the subroutine. If this happens, you should explicitly supply a reasonable value of count on the non-root nodes. (End of advice to users.) And the Fortran binding is MPI_COMM_SPAWN_MULTIPLE(COUNT, ARRAY_OF_COMMANDS, ...) INTEGER COUNT CHARACTER*(*) ARRAY_OF_COMMANDS(*) Intuitively, it seems obvious that 'array_of_commands' is an array of 'count' commands. That being said, the standard does not state that, and it is unclear whether 'array_of_commands' should be NULL-terminated (so to speak) or not. Back to the Fortran binding, the following prototype, which is somehow consistent with 'array_of_argv', could (help to) clear the confusion. The same comments also apply to the Fortran 2008 binding. CHARACTER*(*) ARRAY_OF_COMMANDS(COUNT) Gilles

1 0

Behavior of [Distributed] Graph Topology Constructors when a neighbor is MPI_PROC_NULL
by Mor, Omri 06 Jan '18

06 Jan '18

The standard does not explicitly define what MPI_GRAPH_CREATE, MPI_DIST_GRAPH_CREATE_ADJACENT, and MPI_DIST_GRAPH_CREATE do when a neighbor is MPI_PROC_NULL. Note that neighbors (edges in MPI_GRAPH_CREATE; sources and destinations in MPI_DIST_GRAPH_CREATE_ADJACENT and MPI_DIST_GRAPH_CREATE) are process ranks, so MPI_PROC_NULL should be a valid value. To be consistent with the documentation of MPI_PROC_NULL, which states that "the special value MPI_PROC_NULL can be used instead of a rank wherever a source or a destination argument is required in a call", the graph topology constructors should permit MPI_PROC_NULL as a neighbor. Communication with such a neighbor via the neighborhood collectives should, of course, behave like point-to-point communication with MPI_PROC_NULL; the buffer is neither communicated nor updated, similar to how the neighborhood collectives currently function at the border of non-periodic cartesian topologies (this behavior is also not stated in the standard, but is logical and in Open MPI’s documentation of the neighborhood collectives). This simplifies the process of creating and communicating with mostly-uniform topologies, such as a pseudo-cartesian or binary tree topology.

1 0

Behaviour of not-significant output arguments in MPI
by Christoph Niethammer 14 Aug '17

14 Aug '17

Hello, Studying the MPI 3.1. Standard I went over the question if output arguments, which are not significant to a subgroup of processes may be modified by the MPI call. MPI-3.1, Sect. 2.3. on page 10 lines 42-44 only discusses input arguments, and therefore, the meaning of "not significant" for output arguments is somehow undefined. I would expect, that the values of these arguments are unchanged by MPI calls. An example: In the following code using MPI_Exscan, I cannot clearly say whether the last code line is needed to guarantee the 0 in recv on process 0. > ... > int myrank; > int recv = 0; > MPI_Comm_rank(MPI_COMM_WORLD, &myRank); > MPI_Exscan(&send, &recv, 1, MPI_INT, MPI_SUM, MPI_COMM_WORLD); > if(myRank == 0) { recv = 0; } /* is this necessary according to MPI 3.1 ?*/ I expect, that all real MPI implementations guarantee the 0 on process 0. Best regards Christoph Niethammer -- Christoph Niethammer High Performance Computing Center Stuttgart (HLRS) Nobelstrasse 19 70569 Stuttgart Tel: ++49(0)711-685-87203 email: niethammer(a)hlrs.de http://www.hlrs.de/people/niethammer

1 0