From: Erez Haba <erezh@XXXXXXXXXXXXX>
Date: January 22, 2008 7:10:56 PM CST
To: "mpi-21@mpi-forum.org" <mpi-21@XXXXXXXXXXXXX>
Cc: Dave Goodell <goodell@XXXXXXXXXXX>
Subject: RE: [mpi-21] Proposal EH2 & MPI_INPLACE
Reply-To: mpi-21@XXXXXXXXXXXXX

Funny :) that is exactly what I did in one of my C++ implementations.  
Added an overloaded function that takes on buffer as the in-place  
buffer.

Great suggestion :)

Still we need to resolve the C binding which is what this mail thread  
is about.

.Erez

-----Original Message-----
From: owner-mpi-21@XXXXXXXXXXXXX
On Behalf Of Jeff Squyres
Sent: Tuesday, January 22, 2008 3:01 PM
To: mpi-21@XXXXXXXXXXXXX
Cc: Dave Goodell
Subject: Re: [mpi-21] Proposal EH2 & MPI_INPLACE

Fun stuff!  :-)

I propose a different solution... (let's not just drop "const"
everywhere it creates a problem!)

Have an overloaded C++ binding for the functions in question that only
take 1 buffer that is not const.  If this function is invoked, it can
be assumed that the receive buffer is IN_PLACE.

We have precedent for having multiple different C++ bindings compared
to the C bindings:

- MPI_INIT: Init(int &argc, char **&argv) and Init() (assumes NULL,
NULL)
- MPI_TEST: Test(MPI::Status &status) and Test() (assumes STATUS_IGNORE)
- MPI_WAIT: similar to Test
...and I think the other variants of Test() and Wait().


On Jan 22, 2008, at 5:55 PM, Dave Goodell wrote:

> Erez,
>
> Bronis and Dries are probably referring to collectives like
> MPI_SCATTER that *do* use MPI_IN_PLACE in the recv buffer.  See the
> MPI-2 spec, chapter 7, page 154, line 22:
>
>    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.
>
> -Dave
>
> On Jan 22, 2008, at 4: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
>>>
>>>
>>
>


--
Jeff Squyres
Cisco Systems