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

[Rolf Rabenseifner]

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" <mpiwg-rma at lists.mpi-forum.org>
> To: "Pavan Balaji" <balaji at anl.gov>
> Cc: "Rolf Rabenseifner" <rabenseifner at hlrs.de>, "MPI WG Remote Memory Access working group"
> <mpiwg-rma at lists.mpi-forum.org>
> 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" <balaji at anl.gov>
>> To: "MPI WG Remote Memory Access working group" <mpiwg-rma at lists.mpi-forum.org>
>> Cc: "Pavan Balaji" <balaji at anl.gov>, "Rolf Rabenseifner" <rabenseifner at hlrs.de>,
>> "Jeff Hammond" <jeff.science at gmail.com>
>> 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
>>> <mpiwg-rma at lists.mpi-forum.org> 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 rabenseifner at 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 at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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) .