Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of MPI RMA WG meeting on Sept 21, 2018 - mpiwg-rma

19 Feb 2019

      Dear Pavan and all,

I just found the ticket from Bill, Sep. 19, 2016
and labeled it with wg-rma, MPI-4.0, Chattanooga, reading.
Still within Monday Feb. 18, 2019 deadline for Chattanooga when using Hawaiian timezone ;-) 
Therefore, I'll also send out the Forum-Mail for the reading
before midnight on Hawaii.

I hope, that this is okay for you all.

The further going solution, as proposed by Pavan
should be discussed independently, because also allowing 
MPI_Win_create, i.e., removing the whole restriction,   
may have Performance aspects if the progress implementation
of an MPI library is not identical for MPI_Win_create
and MPI_Win_create_dynamic + MPI_Win_attach.

Pavan, 
  I hope that you can add the pull request
  for this ticket today.

As change-log, I propose

\item
Section~\ref{sec:1sided-lock} on page~\pageref{sec:1sided-lock}.
\newline
The rule that implementors may restrict the use of \RMA/ communication that is synchronized with 
\mpifunc{MPI\_WIN\_LOCK}, \mpifunc{MPI\_WIN\_LOCK\_ALL} and other lock calls
to windows in memory allocated by 
\mpifunc{MPI\_ALLOC\_MEM}, \mpifunc{MPI\_WIN\_ALLOCATE},
or attached with \mpifunc{MPI\_WIN\_ATTACH}, is extended by
memory allocated with \mpifunc{MPI\_WIN\_ALLOCATE\_SHARED}.

----
With this, we have the change-log also visible in the index entry of all related routines,
which helps that people can find the change-log.

Best regards
Rolf 

----- Original Message -----
...
From: "MPI WG Remote Memory Access working group" <[email protected]>
To: "Pavan Balaji" <[email protected]>
Cc: "Rolf Rabenseifner" <[email protected]>, "MPI WG Remote Memory Access working group"
<[email protected]>
Sent: Sunday, February 17, 2019 1:15:53 PM
Subject: Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of MPI RMA WG meeting on Sept 21, 2018
...
...
+1 on removing that text.  The intent was to allow Win_create too, which we
somehow missed.
The original MPI-2 intent was, to allow only memories that were allocated by
an MPI library routine and ***not*** just handed over by the user (as with
MPI_WIN_CREATE).
This means, MPI_WIN_CREATE was originally never intented.
In MPI-2, it was therefore only MPI_ALLOC_MEM.
I do not understand, why MPI_WIN_ATTACH was added to the list.
And I expect that MPI_WIN_ALLOCATE_SHARED was overseen.
But as Jeff said, with MPI_WIN_ATTACH in the list,
this restriction does not make sense anymore.
Is there a ticket resolving this Problem in MPI-4.0
(Deadline seems to be today (or Monday noon?).
Best regards
Rolf
----- Original Message -----
...
From: "Pavan Balaji" <[email protected]>
To: "MPI WG Remote Memory Access working group" <[email protected]>
Cc: "Pavan Balaji" <[email protected]>, "Rolf Rabenseifner" <[email protected]>,
"Jeff Hammond" <[email protected]>
Sent: Wednesday, September 26, 2018 6:16:25 PM
Subject: Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of
MPI RMA WG meeting on Sept 21, 2018
...
...
On Sep 25, 2018, at 9:38 PM, Jeff Hammond via mpiwg-rma
<[email protected]> wrote:
    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),
      MPI_WIN_ALLOCATE_SHARED (Section 11.2.3),
    or attached with MPI_WIN_ATTACH (Section 11.2.4).
    Locks can be used portably only in such memory.
I am not certain that this change is consistent with the original intent, but we
should just remove this text, because it does not make sense anymore.  If
MPI_Win_attach is sufficient to allow locks, then MPI_Win_create should be
there, because one can implement MPI_Win_create in terms of
MPI_Win_create_dynamic+MPI_Win_attach.
+1 on removing that text.  The intent was to allow Win_create too, which we
somehow missed.
-- Pavan
--
Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] .
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
[email protected]
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma
-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] .
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) .

Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of MPI RMA WG meeting on Sept 21, 2018

Rolf Rabenseifner

tags

participants (1)