From: George Bosilca <bosilca@XXXXXXXXXXXX>
Date: January 22, 2008 4:58:59 PM CST
To: mpi-21@XXXXXXXXXXXXX
Subject: Re: [mpi-21] Proposal EH2 & MPI_INPLACE
Reply-To: mpi-21@XXXXXXXXXXXXX

Erez,

There are collective communications that allow MPI_IN_PLACE as the  
receive buffer, MPI_Scatter and MPI_Scatterv. Therefore, they will  
modify the send buffer, which cannot be const in these two cases.  
Here are the sections from the standard related to this.

   george.

Section 7.3.2
Collective communication can occur ``in place'' for  
intracommunicators, with the output buffer being identical to the  
input buffer. This is specified by providing a special argument  
value, MPI_IN_PLACE, instead of the send buffer or the receive buffer  
argument.

 From the MPI_Scatter section:
The ``in place'' option for intracommunicators is specified by  
passing MPI_IN_PLACE as the value of recvbuf at the root. In such  
case, recvcount and recvtype are ignored, and root ``sends'' no data  
to itself. The scattered vector is still assumed to contain n  
segments, where n is the group size; the root-th segment, which root  
should ``send to itself,'' is not moved.

 From the MPI_Scatterv section:
The ``in place'' option for intracommunicators is specified by  
passing MPI_IN_PLACE as the value of recvbuf at the root. In such  
case, recvcount and recvtype are ignored, and root ``sends'' no data  
to itself. The scattered vector is still assumed to contain n  
segments, where n is the group size; the root-th segment, which root  
should ``send to itself,'' is not moved.

On Jan 22, 2008, at 5:45 PM, Erez Haba wrote:

> :) ... and I though I answered the right question (:
>
> Operations that use the MPI_IN_PLACE, specify it as the send-buffer  
> argument. These collectives write into the receive-buffer and not  
> the send-buffer (MPI_IN_PLACE value is used as a flag).
>
> Which is why I don't see the problem. Having the send buffer as  
> const is perfectly alright.
>
> .Erez
>
> -----Original Message-----
> From: owner-mpi-21@mpi-forum.org [mailto:owner-mpi-21@mpi- 
> forum.org] On Behalf Of Bronis R. de Supinski
> Sent: Tuesday, January 22, 2008 2:32 PM
> To: mpi-21@mpi-forum.org
> Subject: RE: [mpi-21] Proposal EH2 & MPI_INPLACE
>
>
> Erez:
>
> The issue at hand was not whether MPI_INPLACE should be const,
> it's whether the send buffer should be const for operations that
> use MPI_INPLACE for the receive buffer. The problem is that the
> send buffer is modified.
>
> Bronis
>
> On Tue, 22 Jan 2008, Erez Haba wrote:
>
>> I don't see the problem, would you care to elaborate?
>>
>> As far as I know the users specifies MPI_IN_PLACE as the sendbuf  
>> and the real read/write buff to the recvbuff. Thus the  
>> implementation read/writes to the recvbuf and not to the  
>> MPI_IN_PLACE value.
>>
>> As a complement to the const proposal we should actually define  
>> MPI_IN_PLACE and a pointer to const (e.g., '#define MPI_IN_PLACE   
>> (const void*)-1'), which will help people avoid making the mistake  
>> of specifying MPI_IN_PLACE to the recv buffer.
>>
>> Thanks,
>> .Erez
>>
>> -----Original Message-----
>> From: owner-mpi-21@mpi-forum.org [mailto:owner-mpi-21@mpi- 
>> forum.org] On Behalf Of Dries Kimpe
>> Sent: Tuesday, January 22, 2008 12:40 PM
>> To: mpi-21@mpi-forum.org
>> Subject: [mpi-21] Proposal EH2 & MPI_INPLACE
>>
>> There is a problem with adding const to the send buffer of some of  
>> the
>> collective operations:
>>
>> Because of MPI_IN_PLACE, in some cases, the send buffer will not be
>> read-only but read-write.
>>
>> Example:
>> MPI_Allreduce
>>
>> Affected:
>> All collectives that support MPI_IN_PLACE --AND-- modify the data  
>> in the send
>> buffer.
>>
>> Solution:
>> Drop the const from the send buffer argument of the affected  
>> functions
>>
>>  Dries
>>
>>
>