From: Jeff Squyres <jsquyres@XXXXXXXXX>
Date: January 22, 2008 5:02:06 PM CST
To: mpi-21@XXXXXXXXXXXXX
Subject: Re: [mpi-21] Proposal EH2 & MPI_INPLACE
Reply-To: mpi-21@XXXXXXXXXXXXX

Actually, Rajeev's point supersedes this whole thread.  :-)


On Jan 22, 2008, at 6:00 PM, Jeff Squyres wrote:

> 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
>


-- 
Jeff Squyres
Cisco Systems