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

Semantic meaning of 'rank' throughout the MPI standard
by Mor, Omri 28 May '19

28 May '19

Hello MPI-Forum: Before submitting an issue to the MPI Forum’s GitHub repository, I’d like to garner some initial feedback. This proposal reaches across a number of WGs, though is likely most relevant to the Semantic Terms WG. Currently, MPI specifies a ‘rank’ argument (such as sources, destinations, roots, and targets) as either an ‘integer’ or a ‘non-negative integer’. This varies by chapter: Point-to-Point Communication, Collective Communication, and ‘Groups, Contexts, Communicators, and Caching’ exclusively uses ‘integer’, while One-Sided Communications uses ‘non-negative integer’ exclusively. The Process Topologies chapter confusingly uses both. Compounding this confusion is how different calls interacts with the null process MPI_PROC_NULL, defined in §3.11. It is unclear, for instance, whether the null process is only permitted in point-to-point communication calls as its definition inside that chapter might imply, or whether it is intended to be more general. That the null process is implemented as a negative integer in all major MPI implementations I am aware of means only worsens the situation. My proposal is then thus: to first define as a semantic term ‘rank’ with the meaning ‘any integer from 0 to N in a group of size N or communicator whose group is size N, along with the integer constant MPI_PROC_NULL’. Most calls with a rank argument can then simply define it as a rank integer. Receive calls additionally need to specify that it can be MPI_ANY_SOURCE. Communication calls with a null process succeed and return as soon as possible, not modifying any arguments to the call. Whether a collective call with a null root process is required to be called by all processes in the group of the communicator before the call returns is unspecified, but collective calls must still be issued in the same order to be correct. Besides implementations possibly needing to implement communication with null processes for a wider range of operations, are there any issues with this proposal? Doing so should be pretty trivial, though it does require an additional branch. As an alternative, it is possible to restrict the use of null processes to point-to-point communication while still merging the definitions of process ranks. For additional comments on the particular use case of null processes in graph topologies, see #87 in the mpi-issues repository. This proposal is both broader as well as not necessarily requiring the support for null processes outside of point-to-point communication; the general purpose is to clarify what values are allowed for rank arguments throughout the MPI standard. Thank you, Omri Mor

1 0

Re: [Mpi-comments] MPI_Create_directory
by Axel Huebl 07 Jan '19

07 Jan '19

Just something that can be structured into a tree on which paths or inodes we declare the already existing MPI-IO files. Not necessarily with all the constrains of POSIX. Basically introducing simple inodes, implemented with supported protocols / transports. Axel On 07.01.19 16:02, William Gropp wrote: > Are we assuming a POSIX filesystem (a bad idea in my opinion)? Are we > assuming a more restricted set of file system structure operations, > along with weaker consistency semantics (matching the MPI-IO approach > rather than POSIX)? > > Bill > > William Gropp > Director and Chief Scientist, NCSA > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > >> On Jan 7, 2019, at 8:28 AM, Axel Huebl via mpi-comments >> <mpi-comments(a)lists.mpi-forum.org >> <mailto:[email protected]>> wrote: >> >> Dear MPI-Forum, >> >> >> should we extend the MPI-I/O interfaces for directory operations? >> Especially a "mkdir -p" equivalent could be useful. >> >> In many scientific apps that create output at scale, an output >> structure needs to be created on demand. >> >> One can of course decide to do so with e.g. Linux `mkdir` but this can >> be tricky: >> >> If all ranks do it, one will race the others and it's unnecessary >> expensive in terms of operations. >> >> If a "root" rank does it, there is no guarantee that e.g. a >> MPI_Barrier which syncs the "MPI-World" will also cause the >> "filesystem-world" to be up-to-date. For example a mkdir on a slow NFS >> local node has bot yet propagated to the other compute nodes. >> >> Comments, feedback and overlooked already existing solutions welcome! >> >> >> Best regards, >> Axel Huebl >> -- >> >> Axel Huebl >> Phone: +49 351 260 3582 >> Institute of Radiation Physics >> http://www.hzdr.de/crp >> Helmholtz-Zentrum Dresden - Rossendorf (HZDR) >> Bautzner Landstr. 400 | 01328 Dresden | Germany >> Board of Directors: >> Prof. Dr. Dr. h. c. Roland Sauerbrey, Dr. Ulrich Breuer >> Company Registration Number VR 1693, Amtsgericht Dresden >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpi-comments > -- Axel Huebl Phone: +49 351 260 3582 Institute of Radiation Physics http://www.hzdr.de/crp Helmholtz-Zentrum Dresden - Rossendorf (HZDR) Bautzner Landstr. 400 | 01328 Dresden | Germany Board of Directors: Prof. Dr. Dr. h. c. Roland Sauerbrey, Dr. Ulrich Breuer Company Registration Number VR 1693, Amtsgericht Dresden

1 0

Re: [Mpi-comments] MPI_Create_directory
by William Gropp 07 Jan '19

07 Jan '19

Are we assuming a POSIX filesystem (a bad idea in my opinion)? Are we assuming a more restricted set of file system structure operations, along with weaker consistency semantics (matching the MPI-IO approach rather than POSIX)? Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign > On Jan 7, 2019, at 8:28 AM, Axel Huebl via mpi-comments <mpi-comments(a)lists.mpi-forum.org> wrote: > > Dear MPI-Forum, > > > should we extend the MPI-I/O interfaces for directory operations? Especially a "mkdir -p" equivalent could be useful. > > In many scientific apps that create output at scale, an output structure needs to be created on demand. > > One can of course decide to do so with e.g. Linux `mkdir` but this can be tricky: > > If all ranks do it, one will race the others and it's unnecessary expensive in terms of operations. > > If a "root" rank does it, there is no guarantee that e.g. a MPI_Barrier which syncs the "MPI-World" will also cause the "filesystem-world" to be up-to-date. For example a mkdir on a slow NFS local node has bot yet propagated to the other compute nodes. > > Comments, feedback and overlooked already existing solutions welcome! > > > Best regards, > Axel Huebl > -- > > Axel Huebl > Phone: +49 351 260 3582 > Institute of Radiation Physics > http://www.hzdr.de/crp > Helmholtz-Zentrum Dresden - Rossendorf (HZDR) > Bautzner Landstr. 400 | 01328 Dresden | Germany > Board of Directors: > Prof. Dr. Dr. h. c. Roland Sauerbrey, Dr. Ulrich Breuer > Company Registration Number VR 1693, Amtsgericht Dresden > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

1 0

MPI_Create_directory
by Axel Huebl 07 Jan '19

07 Jan '19

Dear MPI-Forum, should we extend the MPI-I/O interfaces for directory operations? Especially a "mkdir -p" equivalent could be useful. In many scientific apps that create output at scale, an output structure needs to be created on demand. One can of course decide to do so with e.g. Linux `mkdir` but this can be tricky: If all ranks do it, one will race the others and it's unnecessary expensive in terms of operations. If a "root" rank does it, there is no guarantee that e.g. a MPI_Barrier which syncs the "MPI-World" will also cause the "filesystem-world" to be up-to-date. For example a mkdir on a slow NFS local node has bot yet propagated to the other compute nodes. Comments, feedback and overlooked already existing solutions welcome! Best regards, Axel Huebl -- Axel Huebl Phone: +49 351 260 3582 Institute of Radiation Physics http://www.hzdr.de/crp Helmholtz-Zentrum Dresden - Rossendorf (HZDR) Bautzner Landstr. 400 | 01328 Dresden | Germany Board of Directors: Prof. Dr. Dr. h. c. Roland Sauerbrey, Dr. Ulrich Breuer Company Registration Number VR 1693, Amtsgericht Dresden

1 0

Re: [Mpi-comments] Request: Canonical MPI_Pack_external with different data representations
by Christoph Niethammer 12 Nov '18

12 Nov '18

Hello, I would like to add to the discussion that, Open MPI currently uses external32 for the mentioned MPI_pack_external routine, but as far as I see, an extension to other formats should be straight forward via its converter mechanism. Maybe someone else can comment on the other MPI implementations: MPICH, ... Best Christoph Niethammer ----- Mensaje original ----- De: "mpi-comments" <mpi-comments(a)lists.mpi-forum.org> Para: "mpi-comments" <mpi-comments(a)lists.mpi-forum.org> CC: "Mor, Omri" <omrimor2(a)illinois.edu> Enviados: Viernes, 9 de Noviembre 2018 19:23:18 Asunto: Re: [Mpi-comments] Request: Canonical MPI_Pack_external with different data representations > After more than 20 years, how about making use of the "future extensibility" > for the next standard to introduce more datarep arguments (like e.g. "native”)? It could also be useful to define an “external64” data representation, to support LP64 systems better. Why is MPI_AINT 8 bytes in “external32”? I suppose that it was designed to support the IL32P64 (LLP64) data model, used in Windows. Unrelated, it may also be useful to define an MPI_SIZE_T datatype that can be used with size_t variables. Though I guess MPI_Aint and MPI_AINT can be used for that purpose as well. > I also wonder how to determine the exact size of a pack buffer. > " > A call to MPI_PACK_SIZE(incount, datatype, comm, size) returns in size an upper bound > on the increment in position that is effected by a call to MPI_PACK(inbuf, incount, datatype, > outbuf, outcount, position, comm).[...] > > Rationale. The call returns an upper bound, rather than an exact bound, since the > exact amount of space needed to pack the message may depend on the context (e.g., > first message packed in a packing unit may take more space). (End of rationale.) > "(MPI3.1, p. 135) > There seems not to exist e.g. a routine to add up the sizes (INOUT size instead of position) > analogous to the Pack procedure. Is there a function to determine the extra size for the > first message (see Rationale). > How should the exact buffer size (and not only an upper bound) be determinated before packing? For the canonical MPI_PACK/MPI_UNPACK, there’s MPI_PACK_EXTERNAL_SIZE, which returns the exact size of the pack buffer. For the non-canonical MPI_PACK/MPI_UNPACK, you can only get an upper bound on the pack size, as the function doesn’t know if it’s the first message in a series of pack/unpack calls or not. MPI_PACK may, depending on the implementation, only need to store the header for the first message, while the others can be stored directly; however, MPI_PACK_SIZE can only assume that it’s the first message and thus would need space for the header as well. Omri Mor _______________________________________________ mpi-comments mailing list mpi-comments(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

1 0

Re: [Mpi-comments] Request: Canonical MPI_Pack_external with different data representations
by Mor, Omri 09 Nov '18

09 Nov '18

> After more than 20 years, how about making use of the "future extensibility" > for the next standard to introduce more datarep arguments (like e.g. "native”)? It could also be useful to define an “external64” data representation, to support LP64 systems better. Why is MPI_AINT 8 bytes in “external32”? I suppose that it was designed to support the IL32P64 (LLP64) data model, used in Windows. Unrelated, it may also be useful to define an MPI_SIZE_T datatype that can be used with size_t variables. Though I guess MPI_Aint and MPI_AINT can be used for that purpose as well. > I also wonder how to determine the exact size of a pack buffer. > " > A call to MPI_PACK_SIZE(incount, datatype, comm, size) returns in size an upper bound > on the increment in position that is effected by a call to MPI_PACK(inbuf, incount, datatype, > outbuf, outcount, position, comm).[...] > > Rationale. The call returns an upper bound, rather than an exact bound, since the > exact amount of space needed to pack the message may depend on the context (e.g., > first message packed in a packing unit may take more space). (End of rationale.) > "(MPI3.1, p. 135) > There seems not to exist e.g. a routine to add up the sizes (INOUT size instead of position) > analogous to the Pack procedure. Is there a function to determine the extra size for the > first message (see Rationale). > How should the exact buffer size (and not only an upper bound) be determinated before packing? For the canonical MPI_PACK/MPI_UNPACK, there’s MPI_PACK_EXTERNAL_SIZE, which returns the exact size of the pack buffer. For the non-canonical MPI_PACK/MPI_UNPACK, you can only get an upper bound on the pack size, as the function doesn’t know if it’s the first message in a series of pack/unpack calls or not. MPI_PACK may, depending on the implementation, only need to store the header for the first message, while the others can be stored directly; however, MPI_PACK_SIZE can only assume that it’s the first message and thus would need space for the header as well. Omri Mor

1 0

Request: Canonical MPI_Pack_external with different data representations
by Martin Bernreuther 09 Nov '18

09 Nov '18

Hello, since MPI-2.0 there's a "Canonical MPI_PACK and MPI_UNPACK" (p. 78, section 4.16) (also see e.g. https://www.mpi-forum.org/docs/mpi-2.1/mpi21-report-bw/node83.htm#Node83) which didn't change much over time: " These functions read/write data to/from the buffer in the "external32" data format specified in Section 13.5.2, and calculate the size needed for packing. Their first arguments specify the data format, for future extensibility, but currently the only valid value of the datarep argument is "external32." "(taken from MPI-3.1, p. 138, section 4.3) After more than 20 years, how about making use of the "future extensibility" for the next standard to introduce more datarep arguments (like e.g. "native")? With MPI_PACK for I/O there's a " Advice to users. The type MPI_PACKED is treated as bytes and is not converted. The user should be aware that MPI_PACK has the option of placing a header in the beginning of the pack buﬀer. (End of advice to users.) "(MPI-31, p. 539) A "header" might be undesirable for other programs to read and this seems not to be an issue using MPI_Pack_external with MPI_BYTE, since there is no header: " Rationale. MPI_PACK_EXTERNAL specifies that there is no header on the message and further specifies the exact format of the data. Since MPI_PACK may (and is allowed to) use a header, the datatype MPI_PACKED cannot be used for data packed with MPI_PACK_EXTERNAL. (End of rationale.) "(MPI-31, p. 138) Thus the canonical version seems to have an advantage for MPI-I/O here. However if a user wants to write e.g. "little endian" on an actual x86 architecture, this seems to be excluded by the actual standard. Thank you, Martin Bernreuther P.S.: I also wonder how to determine the exact size of a pack buffer. " A call to MPI_PACK_SIZE(incount, datatype, comm, size) returns in size an upper bound on the increment in position that is effected by a call to MPI_PACK(inbuf, incount, datatype, outbuf, outcount, position, comm).[...] Rationale. The call returns an upper bound, rather than an exact bound, since the exact amount of space needed to pack the message may depend on the context (e.g., first message packed in a packing unit may take more space). (End of rationale.) "(MPI3.1, p. 135) There seems not to exist e.g. a routine to add up the sizes (INOUT size instead of position) analogous to the Pack procedure. Is there a function to determine the extra size for the first message (see Rationale). How should the exact buffer size (and not only an upper bound) be determinated before packing? -- ________________________________________________________________________ Dr.-Ing. Martin Bernreuther University of Stuttgart High Performance Computing Center (HLRS) Nobelstrasse 19 (Office: 1.307) 70569 Stuttgart, Germany Phone: (++49-(0)711) 685-64542 Fax: (++49-(0)711) 685-54542, -87279, -65832 E-Mail: bernreuther(a)hlrs.de URL: http://www.hlrs.de/people/bernreuther/

1 0

Re: [Mpi-comments] mpi-comments Digest, Vol 8, Issue 1
by HOLMES Daniel 13 Sep '18

13 Sep '18

Hi Alain, I could not find anything explicitly stating that MPI_Iprobe would initiate a receive the way MPI_Irecv does. This is because the probe functions do not initiate a receive the way a receive does; they only probe the matching list and report back to the user but do not change what they find there. Your modified example is guaranteed to deadlock using any standard-conforming MPI library. The MPI_SSEND must not complete before a matching receive operation has been started and has matched. The matching receive operation (the MPI_IRECV in rank 1) cannot be reached because the MPI_RECV must not complete before a matching send operation has been started. The matching send operation (the MPI_SEND in rank 0) cannot be reached because the MPI_SSEND is blocked. The MPI_IPROBE is not a receive operation and does not cause a match to happen - it is therefore not relevant to the deadlock situation described above. Your modified example can be fixed by replacing MPI_IPROBE with MPI_MPROBE (note this a blocking function) and replacing MPI_IRECV with MPI_IMRECV, although a nonblocking function immediately followed by a call to MPI_WAIT is better expressed by a blocking function, i.e. MPI_MRECV in this case. The example must use the blocking MPI_MPROBE rather than the nonblocking MPI_IMPROBE because the match for the MPI_SSEND must occur before the MPI_RECV can complete (because that requires the MPI_SEND to be reached in rank 0, which requires that the MPI_SSEND completes, which requires that it must have been matched in rank 1, which requires that the mprobe must be complete not just started). Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 13 Sep 2018, at 15:08, mpi-comments-request(a)lists.mpi-forum.org<mailto:[email protected]> wrote: ----- Original Message ----- 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 End of mpi-comments Digest, Vol 8, Issue 1 ****************************************** The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [Mpi-comments] Non blocking receive of unknown size
by Alain Miniussi 13 Sep '18

13 Sep '18

Gilles, Not so sure, that argument could be made for MPI_Irecv (used in the original code), which is not allowed to deadlook. There is a special send mode called "ready" that explicitly assume that the recv call has been made, but that's just an optimization. From 3.4: "Thus, a send in standard mode can be started whether or not a matching receive has been posted." I kept the MPI_Ssend because it was in the original example, but the question still hold if replaced with MPI_Send which leaves more choice to the implementation. If MPI_Iprobe initiate a reception (which is not explicitly stated, and which is basically my question) the first MPI_Send could just wait for that event and send the data (maybe using the buffered mode). An argument could be made that since the receiver buffer is not provided, and the implementation could choose a communication mode requiring that a user provided buffer to be ready ready. But then the same argument could be made for MPI_PROBE, and state 3.8 that: "The MPI_PROBE, MPI_IPROBE, MPI_MPROBE, and MPI_IMPROBE operations allow incoming messages to be checked for,ï¿½ without actually receiving them." and later on (p 65): "it is not necessary to receive a message immediately after it has been probed for, and the same message may be probed for several times before it is received." So it seems that the implementation is expected to send the size first, for MPI_[IM]probe to look it up, but that the message itself can be kept pending and that the matching send can be kept blocked until the message is actually copied. Put another way, the message size must be made available to the receiver no matter what communication protocol is chosen. Cheers Alain On 13/09/2018 15:24, gilles--- via mpi-comments wrote: > > ï¿½Alain, > > Regardless of what the standard says or how it is interpreted, your > example can simply deadlock if rank 1 returns from MPI_Iprobe() > > before rank 0 calls MPI_Ssend(). > > Cheers, > > Gilles > > ----- Original Message ----- > > 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 > > > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

1 0

Re: [Mpi-comments] Non blocking receive of unknown size
by gilles＠rist.or.jp 13 Sep '18

13 Sep '18

Alain, Regardless of what the standard says or how it is interpreted, your example can simply deadlock if rank 1 returns from MPI_Iprobe() before rank 0 calls MPI_Ssend(). Cheers, Gilles ----- Original Message ----- 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