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

Atomicity of Accumulates
by Simon Schwitanski 16 Aug '17

16 Aug '17

Hello, I have got a question about the atomicity of accumulate operations as described in 11.7.1. It says (page 461, lines 8 - 11): > The previous correctness conditions imply that a location updated by a > call to an accumulate operation cannot be accessed by a load or an RMA > call other than accumulate until the accumulate operation has completed > (at the target). I am a little bit confused about what this actually means: Does it mean that local load accesses on the target are (somehow) delayed if there is an ongoing accumulate operation to the same location? Or does it just mean that concurrent load accesses are forbidden and lead to undefined behavior? And why does this not hold for store accesses? Thanks! Simon

1 0

Re: [mpiwg-rma] MPI Forum Mailing Lists Online Again
by maik peterson 29 May '17

29 May '17

bland, is mpi-rma still alive ? we got the impression they gave up at the end ? nice to see someone working on it, mp 2017-05-26 17:30 GMT+02:00 Bland, Wesley <wesley.bland(a)intel.com>: > The mailing list migration is complete and all of the lists should be > online again. > > Thanks, > Wesley > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma >

1 0

MPI Forum Mailing Lists Online Again
by Bland, Wesley 26 May '17

26 May '17

The mailing list migration is complete and all of the lists should be online again. Thanks, Wesley

1 0

Brief MPI Forum Mailing List Outage on May 26
by Bland, Wesley 25 May '17

25 May '17

Hi folks, All of the mailing lists for the MPI Forum will have a brief outage tomorrow (Friday, May 26th) at 10:00 AM Central US time while Argonne (our gracious mailing list host) migrates a server and we make a quick DNS change to point to the new location. This should be a brief outage and (hopefully) no incoming messages will be lost during the transition, but be aware that messages sent around that time have a chance of not getting delivered depending on your local DNS cache and timing. If you have any questions or concerns about this, please let me know. Thanks, Wesley

1 0

Re: [mpiwg-rma] Mailing List Migration Happening Today
by Bland, Wesley 03 Oct '16

03 Oct '16

The list should be available again. It's possible that things might not work in your particular area yet if your DNS updates slowly. > On Oct 3, 2016, at 9:46 AM, Bland, Wesley <wesley.bland(a)intel.com> wrote: > > After delaying the migration a bit to avoid interrupting the forum meeting and EuroMPI, we're ready to do the migration today. It's possible that there will be some brief outages between now and the end of the day while DNS records are updated and most likely any emails sent today could end up not getting archived correctly. > > Make sure you are using the correct address for this list in the future as any aliases that might have worked in the past will almost certainly not work in the future: > > mpiwg-rma(a)lists.mpi-forum.org > > Thanks, > Wesley > _______________________________________________ mpiwg-rma mailing list mpiwg-rma(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma

1 0

Mailing List Migration Happening Today
by Bland, Wesley 03 Oct '16

03 Oct '16

After delaying the migration a bit to avoid interrupting the forum meeting and EuroMPI, we're ready to do the migration today. It's possible that there will be some brief outages between now and the end of the day while DNS records are updated and most likely any emails sent today could end up not getting archived correctly. Make sure you are using the correct address for this list in the future as any aliases that might have worked in the past will almost certainly not work in the future: mpiwg-rma(a)lists.mpi-forum.org Thanks, Wesley _______________________________________________ mpiwg-rma mailing list mpiwg-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] MPI_Lock... for MPI shared memory
by William Gropp 13 Sep '16

13 Sep '16

I’ve submitted an issue on this. Thanks for noting it. Bill William Gropp Acting Director and Chief Scientist, NCSA Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Sep 13, 2016, at 8:17 AM, William Gropp <wgropp(a)illinois.edu> wrote: > I agree with Jeff - this is a simple errata item to be fixed. > > Bill > > William Gropp > Acting Director and Chief Scientist, NCSA > Director, Parallel Computing Institute > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > On Sep 13, 2016, at 8:09 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> This is a bug in the text that should be fixed by an erratum. >> >> Jeff >> >> Sent from my iPhone >> >>> On Sep 13, 2016, at 5:36 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >>> >>> Hello, >>> >>> my colleague Joseph detected that an MPI implementation is allowed >>> to not allow passive target communication/synchronization (i.e., >>> all forms of MPI_Lock and Unlock) on MPI shared memory windows. >>> >>> Was it intented or is it only a historical review-bug that >>> MPI_WIN_ALLOCATE_SHARED was never added to the list of >>> MPI_ALLOC_MEM (since MPI-2.0), and MPI_WIN_ALLOCATE & >>> MPI_WIN_ATTACH (since MPI-3.0) in the following text. >>> >>> >>> MPI-3.1 Sect. 11.5.3 on page 448 lines 1-12 say >>> >>> "Implementors may restrict the use of RMA communication >>> that is synchronized by lock calls to windows in >>> memory allocated by MPI_ALLOC_MEM (Section 8.2), >>> MPI_WIN_ALLOCATE (Section 11.2.2), or attached with >>> MPI_WIN_ATTACH (Section 11.2.4). >>> Locks can be used portably only in such memory. >>> >>> Rationale. The implementation of passive target >>> communication when Memory is not shared may require >>> an asynchronous software agent. Such an agent can be >>> implemented more easily, and can achieve better >>> performance, if restricted to specially allocated memory. >>> It can be avoided altogether if shared memory is used. >>> It seems natural to impose restrictions that allows >>> one to use shared memory for third party communication >>> in shared memory machines. >>> (End of rationale.)" >>> >>> >>> The rationale not really fits to the current state >>> that MPI_WIN_ALLOCATE_SHARED is missing in the list. >>> It would fit if MPI_WIN_ALLOCATE_SHARED would be added >>> to the list. >>> >>> 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) >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] MPI_Lock... for MPI shared memory
by William Gropp 13 Sep '16

13 Sep '16

I agree with Jeff - this is a simple errata item to be fixed. Bill William Gropp Acting Director and Chief Scientist, NCSA Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Sep 13, 2016, at 8:09 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > This is a bug in the text that should be fixed by an erratum. > > Jeff > > Sent from my iPhone > >> On Sep 13, 2016, at 5:36 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> >> Hello, >> >> my colleague Joseph detected that an MPI implementation is allowed >> to not allow passive target communication/synchronization (i.e., >> all forms of MPI_Lock and Unlock) on MPI shared memory windows. >> >> Was it intented or is it only a historical review-bug that >> MPI_WIN_ALLOCATE_SHARED was never added to the list of >> MPI_ALLOC_MEM (since MPI-2.0), and MPI_WIN_ALLOCATE & >> MPI_WIN_ATTACH (since MPI-3.0) in the following text. >> >> >> MPI-3.1 Sect. 11.5.3 on page 448 lines 1-12 say >> >> "Implementors may restrict the use of RMA communication >> that is synchronized by lock calls to windows in >> memory allocated by MPI_ALLOC_MEM (Section 8.2), >> MPI_WIN_ALLOCATE (Section 11.2.2), or attached with >> MPI_WIN_ATTACH (Section 11.2.4). >> Locks can be used portably only in such memory. >> >> Rationale. The implementation of passive target >> communication when Memory is not shared may require >> an asynchronous software agent. Such an agent can be >> implemented more easily, and can achieve better >> performance, if restricted to specially allocated memory. >> It can be avoided altogether if shared memory is used. >> It seems natural to impose restrictions that allows >> one to use shared memory for third party communication >> in shared memory machines. >> (End of rationale.)" >> >> >> The rationale not really fits to the current state >> that MPI_WIN_ALLOCATE_SHARED is missing in the list. >> It would fit if MPI_WIN_ALLOCATE_SHARED would be added >> to the list. >> >> 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) >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] MPI_Lock... for MPI shared memory
by Jeff Hammond 13 Sep '16

13 Sep '16

This is a bug in the text that should be fixed by an erratum. Jeff Sent from my iPhone > On Sep 13, 2016, at 5:36 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > Hello, > > my colleague Joseph detected that an MPI implementation is allowed > to not allow passive target communication/synchronization (i.e., > all forms of MPI_Lock and Unlock) on MPI shared memory windows. > > Was it intented or is it only a historical review-bug that > MPI_WIN_ALLOCATE_SHARED was never added to the list of > MPI_ALLOC_MEM (since MPI-2.0), and MPI_WIN_ALLOCATE & > MPI_WIN_ATTACH (since MPI-3.0) in the following text. > > > MPI-3.1 Sect. 11.5.3 on page 448 lines 1-12 say > > "Implementors may restrict the use of RMA communication > that is synchronized by lock calls to windows in > memory allocated by MPI_ALLOC_MEM (Section 8.2), > MPI_WIN_ALLOCATE (Section 11.2.2), or attached with > MPI_WIN_ATTACH (Section 11.2.4). > Locks can be used portably only in such memory. > > Rationale. The implementation of passive target > communication when Memory is not shared may require > an asynchronous software agent. Such an agent can be > implemented more easily, and can achieve better > performance, if restricted to specially allocated memory. > It can be avoided altogether if shared memory is used. > It seems natural to impose restrictions that allows > one to use shared memory for third party communication > in shared memory machines. > (End of rationale.)" > > > The rationale not really fits to the current state > that MPI_WIN_ALLOCATE_SHARED is missing in the list. > It would fit if MPI_WIN_ALLOCATE_SHARED would be added > to the list. > > 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) > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

MPI_Lock... for MPI shared memory
by Rolf Rabenseifner 13 Sep '16

13 Sep '16

Hello, my colleague Joseph detected that an MPI implementation is allowed to not allow passive target communication/synchronization (i.e., all forms of MPI_Lock and Unlock) on MPI shared memory windows. Was it intented or is it only a historical review-bug that MPI_WIN_ALLOCATE_SHARED was never added to the list of MPI_ALLOC_MEM (since MPI-2.0), and MPI_WIN_ALLOCATE & MPI_WIN_ATTACH (since MPI-3.0) in the following text. MPI-3.1 Sect. 11.5.3 on page 448 lines 1-12 say "Implementors may restrict the use of RMA communication that is synchronized by lock calls to windows in memory allocated by MPI_ALLOC_MEM (Section 8.2), MPI_WIN_ALLOCATE (Section 11.2.2), or attached with MPI_WIN_ATTACH (Section 11.2.4). Locks can be used portably only in such memory. Rationale. The implementation of passive target communication when Memory is not shared may require an asynchronous software agent. Such an agent can be implemented more easily, and can achieve better performance, if restricted to specially allocated memory. It can be avoided altogether if shared memory is used. It seems natural to impose restrictions that allows one to use shared memory for third party communication in shared memory machines. (End of rationale.)" The rationale not really fits to the current state that MPI_WIN_ALLOCATE_SHARED is missing in the list. It would fit if MPI_WIN_ALLOCATE_SHARED would be added to the list. 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