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
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
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
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)
TL;DR - The DNS records for the MPI Forum will be moving from Illinois to Google tonight<http://airmail.calendar/2016-09-06%2019:00:00%20CDT>. This should have user impact, but it’s possible that there will be a short outage depending on your local DNS caches. Other services will be migrating soon.
More Details - As part of the overall migration process that I referenced in an email about a month ago, we’re moving the DNS records out of the University of Illinois and up to the cloud (in this case, Google Domains). This should have no impact on your ability to view websites or send emails to these mailing lists, but it’s possible that as the new DNS information propagates to all of the caches around the world, there will be some brief outages. For now, nothing should change.
If everything goes well tonight<http://airmail.calendar/2016-09-06%2019:00:00%20CDT>, I hope to start migrating services next week (with the intention of having everything migrated before the 14th<http://airmail.calendar/2016-09-06%2012:00:00%20CDT> so we can make sure everything is stable for EuroMPI and the September MPI Forum meeting.
Here is the rough timeline:
Sometime this week - Move DNS records from UIUC to Google (hard to predict exactly when this happens)
This week - Prepare mailing lists (moving from Indiana to Argonne) and website (website preview available at https://mpi-forum.github.io/) for move.
Early next week - Move mailing lists and website to their new hosts
September 14th<http://airmail.calendar/2016-09-14%2012:00:00%20CDT> - Migration complete (anything not migrated will be postponed until after the EuroMPI/MPI Forum meeting)
If you have questions/concerns about the migration, new website, mailing lists, etc., please let me know.
Thanks,
Wesley
