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

Jim Dinan dinan at mcs.anl.gov
Wed Jul 18 13:46:02 CDT 2012


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
>




More information about the mpiwg-rma mailing list