September 2012 - mpiwg-rma - mailman3.cels.anl.gov

[Mpi3-rma] Fwd: [Mpi-forum] MPI 3.0 overview
by William Gropp 15 Sep '12

15 Sep '12

I've received some slides (thanks!) but no offers to prepare the slides. If I don't hear from anyone by the time I arrive in Chicago (around 2pm Saturday), I'll put some together to send Rich. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign Begin forwarded message: > From: William Gropp <wgropp(a)illinois.edu> > Subject: Fwd: [Mpi-forum] MPI 3.0 overview > Date: September 7, 2012 9:52:10 PM GMT+02:00 > To: MPI 3.0 Remote Memory Access working group <mpi3-rma(a)lists.mpi-forum.org> > > One of us needs to provide this. There are the slides that we've used for the forum itself, and abbreviated versions of these. I'm working on the standard updates - is someone able to prepare these slides for Rich? > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > Begin forwarded message: > >> From: Richard Graham <richardg(a)mellanox.com> >> Subject: [Mpi-forum] MPI 3.0 overview >> Date: September 4, 2012 2:17:29 AM GMT+02:00 >> To: "mpi-forum(a)lists.mpi-forum.org" <mpi-forum(a)lists.mpi-forum.org> >> Reply-To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> >> >> In preparation for presentations on the MPI 3.0 standard, I would like to ask that the working groups send a few slides on the following new additions to the MPI standard: >> >> - Nonblocking collectives >> - RMA enhancements >> - MPI Tool Interface >> - New Fortran bindings >> - Sparse collectives >> - Enhanced Datatype support >> - Distributed Graph >> - Noncollective communicator creation >> >> Also, if your working group had items that did not make it into MPI-3.0, and would like these mentioned in the same talk, please provide me with some slides. It is good to let folks know why some items did not make it into the standard. >> >> It would be very helpful if I could get these slides by Sept the 12th. >> >> Thanks, >> Rich >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

[Mpi3-rma] MPI_LOCK
by Hubert Ritzdorf 13 Sep '12

13 Sep '12

Hi, I don't know whether it's really important. But there isn't a definition of MPI_LOCK_EXCLUSIVE and MPI_LOCK_SHARED in the MPI document. You can get it out of the names, Example 11.5 and and possibly the definition of MPI_Win_lock_all, but I don't know whether this is sufficient for the MPI standard. Hubert

1 0

Re: [Mpi3-rma] Urgent: Target displacement sign issue
by Jim Dinan 12 Sep '12

12 Sep '12

Hi Sayantan, This will require more discussion, so we'll have to handle it in the MPI 3.0 errata. The proposed solution should not impact communication, it is only to enable full addresses (displacements in dynamic windows) to be passed as the displacement argument to get/put/acc/etc without generating an error. ~Jim. On 9/12/12 4:17 PM, Sur, Sayantan wrote: > Hi Jim, > > Wondering what happened to this issue. I see that Rich sent a message saying the final version has been uploaded. > > Anyways, I'm not sure if this would have qualified as a "ticket-0" change. While the solution proposed is portable, this requires the target to communicate with the origin. For PGAS languages, this would mean probably broadcasting this address to every other process in the job. Alternatively, this could be done in an on-demand basis upon first PGAS put or get. > > Not that it is a big deal, just a significant change to come late. MPI-next? > > Thanks. > > === > Sayantan Sur, Ph.D. > Intel Corp. > >> -----Original Message----- >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- >> bounces(a)lists.mpi-forum.org] On Behalf Of Jim Dinan >> Sent: Wednesday, September 12, 2012 8:36 AM >> To: mpi3-rma(a)lists.mpi-forum.org >> Subject: [Mpi3-rma] Urgent: Target displacement sign issue >> >> Hi All, >> >> We're down to the wire on this change. As specified, dynamic windows will >> /not/ work reliably in MPI 3.0. We currently see "negative" >> displacements for dynamic windows in MPICH on 32-bit platforms. >> Earlier, I suggested a change stating that the implementation will ignore the >> sign for dynamic windows. Here's a revised proposal. >> >> In the paragraph on page 425, line 1, add the bracketed sentence: >> >> In the case of a window created with MPI_WIN_CREATE_DYNAMIC, the >> target_disp for all RMA functions is the address at the target; i.e., the >> effective window_base is MPI_BOTTOM and the disp_unit is one. [Thus, for >> dynamic windows, the target_disp argument to RMA communication >> operations is not restricted to non-negative values.] Users should use >> MPI_GET_ADDRESS at the target process to determine the address of a >> target memory location and communicate this address to the origin process. >> >> ~Jim. >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] Urgent: Target displacement sign issue
by William Gropp 12 Sep '12

12 Sep '12

I think this is fine. Any other comments? Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Sep 12, 2012, at 5:36 PM, Jim Dinan wrote: > Hi All, > > We're down to the wire on this change. As specified, dynamic windows will /not/ work reliably in MPI 3.0. We currently see "negative" displacements for dynamic windows in MPICH on 32-bit platforms. Earlier, I suggested a change stating that the implementation will ignore the sign for dynamic windows. Here's a revised proposal. > > In the paragraph on page 425, line 1, add the bracketed sentence: > > In the case of a window created with MPI_WIN_CREATE_DYNAMIC, the target_disp for all RMA functions is the address at the target; i.e., the effective window_base is MPI_BOTTOM and the disp_unit is one. [Thus, for dynamic windows, the target_disp argument to RMA communication operations is not restricted to non-negative values.] Users should use MPI_GET_ADDRESS at the target process to determine the address of a target memory location and communicate this address to the origin process. > > ~Jim. > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] Urgent: Target displacement sign issue
by Sur, Sayantan 12 Sep '12

12 Sep '12

Hi Jim, Wondering what happened to this issue. I see that Rich sent a message saying the final version has been uploaded. Anyways, I'm not sure if this would have qualified as a "ticket-0" change. While the solution proposed is portable, this requires the target to communicate with the origin. For PGAS languages, this would mean probably broadcasting this address to every other process in the job. Alternatively, this could be done in an on-demand basis upon first PGAS put or get. Not that it is a big deal, just a significant change to come late. MPI-next? Thanks. === Sayantan Sur, Ph.D. Intel Corp. > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > bounces(a)lists.mpi-forum.org] On Behalf Of Jim Dinan > Sent: Wednesday, September 12, 2012 8:36 AM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: [Mpi3-rma] Urgent: Target displacement sign issue > > Hi All, > > We're down to the wire on this change. As specified, dynamic windows will > /not/ work reliably in MPI 3.0. We currently see "negative" > displacements for dynamic windows in MPICH on 32-bit platforms. > Earlier, I suggested a change stating that the implementation will ignore the > sign for dynamic windows. Here's a revised proposal. > > In the paragraph on page 425, line 1, add the bracketed sentence: > > In the case of a window created with MPI_WIN_CREATE_DYNAMIC, the > target_disp for all RMA functions is the address at the target; i.e., the > effective window_base is MPI_BOTTOM and the disp_unit is one. [Thus, for > dynamic windows, the target_disp argument to RMA communication > operations is not restricted to non-negative values.] Users should use > MPI_GET_ADDRESS at the target process to determine the address of a > target memory location and communicate this address to the origin process. > > ~Jim. > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] MPI_WIN_CREATE_DYNAMIC and target_disp
by Hubert Ritzdorf 12 Sep '12

12 Sep '12

Hi Jim, MPI_Get_address() returns the address (displacement) relative to MPI_BOTTOM. This initial address zero is indicated by the constant MPI_BOTTOM. In C, MPI_Bottom is a defined constant and the value is 0. In Fortran, MPI_BOTTOM is a variable in a common block which is located anywhere in memory. The address is constant for the application. But the address of MPI_BOTTOM may be dependent on the application, compiler, .. The value of MPI_BOTTOM is not relevant in MPI Implementations for Fortran. There is no (official) pointer arithmetic in Fortran. Non-negative disp was correct for windows created by MPI_Win_create since the base address of a contiguous window region was transferred to MPI_Win_Create. Non_negative disp is still correct for MPI_Win_Allocate and MPI_Win_allocate_shared. This is not correct for windows created MPI_Win_dynamic (at least in Fortran). Hubert ________________________________________ From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] Sent: Wednesday, September 12, 2012 5:04 PM To: mpi3-rma(a)lists.mpi-forum.org Subject: Re: [Mpi3-rma] MPI_WIN_CREATE_DYNAMIC and target_disp Hi Hubert, Thanks for weighing in on the Fortran side of this issue. IIUC, are you saying that the dynamic window displacement should be relative to the location of MPI_BOTTOM? The intent of the working group was that the displacement should be relative to the /value/ of MPI_BOTTOM, which is assumed to be NULL. Unfortunately, removing "non-negative" from the target_disp argument in MPI_{GET, RGET, PUT, RPUT, ACCUMULATE, ...} is a bigger change than we can make at this stage. ~Jim. On 9/5/12 10:50 AM, Hubert Ritzdorf wrote: > Hi, > > dependent on the actual discussion, I propose a change in the current > version of MPI 3.0 draft. > I send it to the rma list instead of mpi-comments list in order to get > one of the discussed > changes or this change into the MPI document: > > The argument target_disp in the RMA function MPI_{GET, RGET, PUT, RPUT, > ACCUMULATE, ...} > is qualified as non-negative integer. I think, that this cannot be > guaranteed for the Fortran version of > new function MPI_WIN_CREATE_DYNAMIC. The displacement is actually > relative to > MPI_BOTTOM which is a variable in a common block or module. > > The location of MPI_BOTTOM may be dependent on compiler (and possibly > compiler options) > and the sequence of common blocks/modules in memory. > (Example: The memory of a window might be located in a common block, > which is located > in front of the common block which contains MPI_BOTTOM). > Therefore, non-negative displacements cannot be guaranteed for windows > created > by MPI_WIN_CREATE_DYNAMIC in Fortran . > > The simple change would be to remove "non-negative". But I assume that a > rationale would be required. > > Hubert > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma Click https://www.mailcontrol.com/sr/!19pCLlfG47TndxI!oX7UrJwzC7nuAWDdK6MjdrJUqRl… to report this email as spam.

1 0

[Mpi3-rma] Urgent: Target displacement sign issue
by Jim Dinan 12 Sep '12

12 Sep '12

Hi All, We're down to the wire on this change. As specified, dynamic windows will /not/ work reliably in MPI 3.0. We currently see "negative" displacements for dynamic windows in MPICH on 32-bit platforms. Earlier, I suggested a change stating that the implementation will ignore the sign for dynamic windows. Here's a revised proposal. In the paragraph on page 425, line 1, add the bracketed sentence: In the case of a window created with MPI_WIN_CREATE_DYNAMIC, the target_disp for all RMA functions is the address at the target; i.e., the effective window_base is MPI_BOTTOM and the disp_unit is one. [Thus, for dynamic windows, the target_disp argument to RMA communication operations is not restricted to non-negative values.] Users should use MPI_GET_ADDRESS at the target process to determine the address of a target memory location and communicate this address to the origin process. ~Jim.

1 0

Re: [Mpi3-rma] MPI_WIN_CREATE_DYNAMIC and target_disp
by Jim Dinan 12 Sep '12

12 Sep '12

Hi Hubert, Thanks for weighing in on the Fortran side of this issue. IIUC, are you saying that the dynamic window displacement should be relative to the location of MPI_BOTTOM? The intent of the working group was that the displacement should be relative to the /value/ of MPI_BOTTOM, which is assumed to be NULL. Unfortunately, removing "non-negative" from the target_disp argument in MPI_{GET, RGET, PUT, RPUT, ACCUMULATE, ...} is a bigger change than we can make at this stage. ~Jim. On 9/5/12 10:50 AM, Hubert Ritzdorf wrote: > Hi, > > dependent on the actual discussion, I propose a change in the current > version of MPI 3.0 draft. > I send it to the rma list instead of mpi-comments list in order to get > one of the discussed > changes or this change into the MPI document: > > The argument target_disp in the RMA function MPI_{GET, RGET, PUT, RPUT, > ACCUMULATE, ...} > is qualified as non-negative integer. I think, that this cannot be > guaranteed for the Fortran version of > new function MPI_WIN_CREATE_DYNAMIC. The displacement is actually > relative to > MPI_BOTTOM which is a variable in a common block or module. > > The location of MPI_BOTTOM may be dependent on compiler (and possibly > compiler options) > and the sequence of common blocks/modules in memory. > (Example: The memory of a window might be located in a common block, > which is located > in front of the common block which contains MPI_BOTTOM). > Therefore, non-negative displacements cannot be guaranteed for windows > created > by MPI_WIN_CREATE_DYNAMIC in Fortran . > > The simple change would be to remove "non-negative". But I assume that a > rationale would be required. > > Hubert > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] [Mpi-comments] Freeing memory allocated in MPI_WIN_ALLOCATE_SHARED
by Rajeev Thakur 12 Sep '12

12 Sep '12

> > For the above change, the preceding sentence on lines 3-4 would also need to be deleted, namely, the sentence > "The memory associated with windows created by a call to MPI_WIN_CREATE may be freed after the call returns." No, this sentence is ok. I misread it. Rajeev On Sep 12, 2012, at 9:58 AM, Rajeev Thakur wrote: >> Page 415, Line 5: >> Replace >> MPI_WIN_FREE will free the window memory that was allocated in MPI_WIN_ALLOCATE. >> by >> \mpifunc{MPI\_WIN\_FREE} might detach or free the window memory. The specific window creation and >> attach functions specify effects on the window memory by \mpifunc{MPI\_WIN\_FREE}. > > For the above change, the preceding sentence on lines 3-4 would also need to be deleted, namely, the sentence > "The memory associated with windows created by a call to MPI_WIN_CREATE may be freed after the call returns." > > The suggested sentence to be added says that the window attach function also specifies the effects on window memory by Win_free, but there is nothing in MPI_Win_attach about what happens in free. > > That is why I said the simple sentence suggested by Jim was best at this late stage. It's not because it is ok to enumerate the list, but it is easier than getting all the other changes right on short notice. > > Rajeev > > > On Sep 12, 2012, at 9:13 AM, William Gropp wrote: > >> Thanks. I like this proposal. Should I include it in the draft update? Let me know ASAP, as we are running out of time to make changes. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Sep 11, 2012, at 11:29 AM, Hubert Ritzdorf wrote: >> >>> Hi Torsten, >>> >>> I agree. What's about this proposal for which Bill was asking: >>> >>> Page 407, after Line 46 (relative to mpi3,0_draft2.pdf): >>> \mpifunc{MPI\_WIN\_FREE} will free the window memory that was allocated in >>> \mpifunc{MPI\_WIN\_ALLOCATE}. >>> >>> Page 409, after Line 29: >>> \mpifunc{MPI\_WIN\_FREE} will free the window memory that was allocated in >>> \mpifunc{MPI\_WIN\_ALLOCATE\_SHARED}. >>> >>> Page 415, Line 5: >>> Replace >>> MPI_WIN_FREE will free the window memory that was allocated in MPI_WIN_ALLOCATE. >>> by >>> \mpifunc{MPI\_WIN\_FREE} might detach or free the window memory. The specific window creation and >>> attach functions specify effects on the window memory by \mpifunc{MPI\_WIN\_FREE}. >>> >>> Page 415, Line 6-8: >>> To be consistent, the text "Freeing a window that was created with ..." should be removed and >>> mainly moved to: >>> >>> Page 414, after Line 3: >>> >>> \mpifunc{MPI\_WIN\_FREE) will detach all associated memory; i.e. it has the same effect >>> as if all attached memory was detached by calls to \mpifunc{MPI\_WIN\_DETACH}. >>> >>> Hubert >>> >>> ________________________________________ >>> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Torsten Hoefler [htor(a)illinois.edu] >>> Sent: Tuesday, September 11, 2012 9:14 AM >>> To: MPI 3.0 Remote Memory Access working group >>> Subject: Re: [Mpi3-rma] [Mpi-comments] Freeing memory allocated in MPI_WIN_ALLOCATE_SHARED >>> >>> On Mon, Sep 10, 2012 at 04:45:15PM -0500, Rajeev Thakur wrote: >>>> I think the wording Jim suggested is the simplest for now: >>>> >>>> If the window was created with \mpifunc{MPI\_WIN\_ALLOCATE} or >>>> \mpifunc{MPI\_WIN\_ALLOCATE\_SHARED}, \mpifunc{MPI\_WIN\_FREE} will >>>> free the window memory that was allocated during window creation. >>> I'd really like to avoid such lists. I vote to add a sentence to the two >>> creation functions that win_free (with a forward reference) will free >>> the allocated memory (and remove the existing sentence in win_free). >>> This will avoid inconsistencies in the future and seems rather >>> uncontroversial. >>> >>> Torsten >>> >>> >>> -- >>> ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- >>> Torsten Hoefler | Assistant Professor >>> Dept. of Computer Science | ETH Zï¿½rich >>> Universitï¿½tsstrasse 6 | Zurich-8092, Switzerland >>> CAB E 64.1 | Phone: +41 76 309 79 29 >>> _______________________________________________ >>> mpi3-rma mailing list >>> mpi3-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>> >>> >>> Click https://www.mailcontrol.com/sr/kA9!XnKJn2vTndxI!oX7Uqfv98hA5qiofHZG1eUPj2Qg… to report this email as spam. >>> >>> _______________________________________________ >>> mpi3-rma mailing list >>> mpi3-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] [Mpi-comments] Freeing memory allocated in MPI_WIN_ALLOCATE_SHARED
by Rajeev Thakur 12 Sep '12

12 Sep '12

> Page 415, Line 5: > Replace > MPI_WIN_FREE will free the window memory that was allocated in MPI_WIN_ALLOCATE. > by > \mpifunc{MPI\_WIN\_FREE} might detach or free the window memory. The specific window creation and > attach functions specify effects on the window memory by \mpifunc{MPI\_WIN\_FREE}. For the above change, the preceding sentence on lines 3-4 would also need to be deleted, namely, the sentence "The memory associated with windows created by a call to MPI_WIN_CREATE may be freed after the call returns." The suggested sentence to be added says that the window attach function also specifies the effects on window memory by Win_free, but there is nothing in MPI_Win_attach about what happens in free. That is why I said the simple sentence suggested by Jim was best at this late stage. It's not because it is ok to enumerate the list, but it is easier than getting all the other changes right on short notice. Rajeev On Sep 12, 2012, at 9:13 AM, William Gropp wrote: > Thanks. I like this proposal. Should I include it in the draft update? Let me know ASAP, as we are running out of time to make changes. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Sep 11, 2012, at 11:29 AM, Hubert Ritzdorf wrote: > >> Hi Torsten, >> >> I agree. What's about this proposal for which Bill was asking: >> >> Page 407, after Line 46 (relative to mpi3,0_draft2.pdf): >> \mpifunc{MPI\_WIN\_FREE} will free the window memory that was allocated in >> \mpifunc{MPI\_WIN\_ALLOCATE}. >> >> Page 409, after Line 29: >> \mpifunc{MPI\_WIN\_FREE} will free the window memory that was allocated in >> \mpifunc{MPI\_WIN\_ALLOCATE\_SHARED}. >> >> Page 415, Line 5: >> Replace >> MPI_WIN_FREE will free the window memory that was allocated in MPI_WIN_ALLOCATE. >> by >> \mpifunc{MPI\_WIN\_FREE} might detach or free the window memory. The specific window creation and >> attach functions specify effects on the window memory by \mpifunc{MPI\_WIN\_FREE}. >> >> Page 415, Line 6-8: >> To be consistent, the text "Freeing a window that was created with ..." should be removed and >> mainly moved to: >> >> Page 414, after Line 3: >> >> \mpifunc{MPI\_WIN\_FREE) will detach all associated memory; i.e. it has the same effect >> as if all attached memory was detached by calls to \mpifunc{MPI\_WIN\_DETACH}. >> >> Hubert >> >> ________________________________________ >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Torsten Hoefler [htor(a)illinois.edu] >> Sent: Tuesday, September 11, 2012 9:14 AM >> To: MPI 3.0 Remote Memory Access working group >> Subject: Re: [Mpi3-rma] [Mpi-comments] Freeing memory allocated in MPI_WIN_ALLOCATE_SHARED >> >> On Mon, Sep 10, 2012 at 04:45:15PM -0500, Rajeev Thakur wrote: >>> I think the wording Jim suggested is the simplest for now: >>> >>> If the window was created with \mpifunc{MPI\_WIN\_ALLOCATE} or >>> \mpifunc{MPI\_WIN\_ALLOCATE\_SHARED}, \mpifunc{MPI\_WIN\_FREE} will >>> free the window memory that was allocated during window creation. >> I'd really like to avoid such lists. I vote to add a sentence to the two >> creation functions that win_free (with a forward reference) will free >> the allocated memory (and remove the existing sentence in win_free). >> This will avoid inconsistencies in the future and seems rather >> uncontroversial. >> >> Torsten >> >> >> -- >> ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- >> Torsten Hoefler | Assistant Professor >> Dept. of Computer Science | ETH Zï¿½rich >> Universitï¿½tsstrasse 6 | Zurich-8092, Switzerland >> CAB E 64.1 | Phone: +41 76 309 79 29 >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> >> Click https://www.mailcontrol.com/sr/kA9!XnKJn2vTndxI!oX7Uqfv98hA5qiofHZG1eUPj2Qg… to report this email as spam. >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0