[Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?

[Rajeev Thakur]

There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there  any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets.

Rajeev


On Jul 22, 2012, at 10:55 AM, Torsten Hoefler wrote:

> Dear All,
> 
> I think we should discuss this more. Right now, we still have more votes
> in favor of this than against. The change is still committed and part of
> the "official release". The deadline is 7/26. 
> 
> Please advise what to do!
> 
> Thanks,
>  Torsten
> 
> On Wed, Jul 18, 2012 at 08:11:23PM +0000, Barrett, Brian W wrote:
>> I'm concerned with the change (and don't think it should happen at this point, as I want to be able to tell other people their changes are too big).  It's probably not another O(p) structure, since a process will have to know the other rank's disp_unit to do the memcpy during the communication operations, so we crossed the O(p) bridge when we added disp_unit to allocate_shared.
>> 
>> 
>> Brian
>> 
>> --
>>  Brian W. Barrett
>>  Scalable System Software Group
>>  Sandia National Laboratories
>> ________________________________________
>> From: mpi3-rma-bounces at lists.mpi-forum.org [mpi3-rma-bounces at lists.mpi-forum.org] on behalf of Jim Dinan [dinan at mcs.anl.gov]
>> Sent: Wednesday, July 18, 2012 12:46 PM
>> To: mpi3-rma at lists.mpi-forum.org
>> Subject: [EXTERNAL] Re: [Mpi3-rma] Disp_unit in allocate_shared should be returned by win_shared_query?
>> 
>> It's not inherently damaging, but it requires us to maintain/provide
>> access to another O(p) structure and suggests to users that another
>> process' disp_unit is useful information, which is incorrect.  IIRC, we
>> did discuss this in the working group and intentionally omitted it.
>> 
>>  ~Jim.
>> 
>> On 7/18/12 1:38 PM, Torsten Hoefler wrote:
>>> On Wed, Jul 18, 2012 at 01:18:53PM -0500, James Dinan wrote:
>>>> On 7/18/12 1:06 PM, Torsten Hoefler wrote:
>>>>> On Wed, Jul 18, 2012 at 01:08:43PM -0500, Pavan Balaji wrote:
>>>>>> 
>>>>>> On 07/18/2012 01:02 PM, Torsten Hoefler wrote:
>>>>>>> Jim,
>>>>>>>> Is one process' disp_unit meaningful at another process?  I thought that
>>>>>>>> this is not the case.  MPI provides no other routines to query another
>>>>>>>> process' disp_unit.
>>>>>>> It is something that the user is passing in. I don't know of a
>>>>>>> particular use-case but we can query all other arguments that each
>>>>>>> process passed. One more integer seemed safe to me.
>>>>>>> 
>>>>>>>> Also, what meaning does a disp_unit have in the context of load/store
>>>>>>>> operations that will result from win_shared_query?
>>>>>>> Nothing.
>>>>>>> 
>>>>>>>> Maybe I'm missing something, but this doesn't seem necessary.
>>>>>>> Well, it's better to have it than to introduce it with a different name
>>>>>>> later. That was my main motivation. One could also use it in a library
>>>>>>> context to query. But that's weak, I know.
>>>>>> 
>>>>>> This doesn't seem critical, and can always be added in MPI-3.1 if we
>>>>>> find it necessary.  No reason to rush it.
>>>>> 
>>>>> It cannot be added without a new function name. That was the concern
>>>>> here. Adding it seems less risk than not adding it. In addition, it is
>>>>> already added ;-).
>>>> 
>>>> I am concerned that this is a harmful change.  The disp_unit from one
>>>> process has no meaningful use at another process.  If the user wants to
>>>> know it for some reason, they can use a separate communication operation.
>>> I believe the potential damage is very limited. But we can have a vote.
>>> 
>>> So far it's still yes: 5, no: 1
>>> 
>>> I'm just mediating, not making decisions.
>>> 
>>> Torsten
>>> 
>> 
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>> 
>> 
>> 
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>> 
> 
> -- 
> ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ -----
> Torsten Hoefler         | Performance Modeling and Simulation Lead
> Blue Waters Directorate | University of Illinois (UIUC)
> 1205 W Clark Street     | Urbana, IL, 61801
> NCSA Building           | +01 (217) 244-7736
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma