From: "Rajeev Thakur" <thakur@XXXXXXXXXXX>
Date: January 22, 2008 10:12:14 PM CST
To: <mpi-21@XXXXXXXXXXXXX>
Subject: RE: [mpi-21] Proposal EH2 & MPI_INPLACE
Reply-To: mpi-21@XXXXXXXXXXXXX

Each collective function defines specifically how MPI_IN_PLACE is to  
be used
for that collective. One has to look at the definition of each  
function to
know how to use MPI_IN_PLACE for that function. It cannot be used  
randomly
as sendbuf or recvbuf. Only scatter and scatterv allow it to be used  
as as
the sendbuf, and that too only at the root, and it is specified that  
no data
is copied into the sendbuf on the root. So I think it is ok to define  
it as
const.

Rajeev

> -----Original Message-----
> From: owner-mpi-21@mpi-forum.org
> [mailto:owner-mpi-21@mpi-forum.org] On Behalf Of Erez Haba
> Sent: Tuesday, January 22, 2008 7:40 PM
> To: mpi-21@mpi-forum.org
> Subject: RE: [mpi-21] Proposal EH2 & MPI_INPLACE
>
> Thanks,
>
> Okay that is my bad, I should have look carefully at the
> different MPI collectives. The original mail was about
> MPI_Allreduce where there is not issue. But I definitely see
> your point about MPI_Scatter and MPI_Scatterv. As part of the
> *const* keyword work-group we'll look carefully at all the
> collectives and probably take Dries suggestion for those that
> the send-buffer is modified.
>
> .Erez
>
> P.S. updating the send buffer? This is a no-no, there must be
> some mistake.
>
> -----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 3:58 PM
> To: mpi-21@mpi-forum.org
> Subject: RE: [mpi-21] Proposal EH2 & MPI_INPLACE
>
>
> Erez:
>
> Re:
>> :) ... 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).
>
> That is incorrect (or rather inexact). Refer to:
>
> http://www.mpi-forum.org/docs/mpi-20-html/node145.htm#Node145
>
> Specifically:
>
> This is specified by providing a special argument value,
> MPI_IN_PLACE, instead of the send buffer or the receive
> buffer argument.
>
> So, it can replace either argument. Thus, the send buffer
> cannot be const since it can be modified when MPI_IN_PLACE is
> used for the receive buffer.
>
> Bronis
>
>
>
>> 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
>>>
>>>
>>
>>
>
>