[Mpi3-rma] RMA telecon, 1/24, noon Central

[James Dinan]

Hi Pavan,

Is the justification for the window argument that a system could use 
both RMA methods and thus have some windows that are MPI_RMA_UNIFIED and 
some that are MPI_RMA_SEPARATE (maybe host memory and accelerator memory 
or something like that)?  If this is the intent, have we also added a 
mechanism (e.g. info argument) to request an RMA mode for a window?

  ~Jim.

On 1/22/11 4:58 PM, Pavan Balaji wrote:
>
> Btw, the MPI_RMA_QUERY function still seems to take a "datatype" and
> "op" argument. As we have discussed in the past many telecons and
> Forums, this should not be required. It should only take the window
> input argument, and the result as an output argument.
>
> -- Pavan
>
> On 01/22/2011 03:39 PM, Pavan Balaji wrote:
>> All,
>>
>> I've attached the merged proposals with the parts that we decided to
>> merge into proposal 1.
>>
>> All of the new additions are in red. The parts that we decided to drop
>> are in purple (I can easily delete them).
>>
>> Torsten: should I commit these changes into the svn repository?
>>
>> -- Pavan
>>
>> On 01/19/2011 09:51 PM, Torsten Hoefler wrote:
>>> Hello,
>>>
>>> I just updated the version on the page (after more discussions with
>>> Brian). We have one more comment to discuss at the telecon and one
>>> change. See:
>>>
>>> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-proposal1/
>>>
>>>
>>> Brian also discovered that the definition of the sync call could be
>>> misinterpreted to be blocking (if a transfer is in progress from A to B
>>> and B calls synch, which itself might now depend on the completion of
>>> the transfer). I think it is defined as nonblocking and thus might
>>> return a buffer in an inconsistent state (which is now the user's
>>> problem). Any opinions?
>>>
>>> Thanks& All the Best,
>>> Torsten
>>>
>>> PS: The latex diff is:
>>>
>>> ---
>>> @@ -2098,8 +2098,12 @@
>>> specifies the set of origin processes for that
>>> epoch.
>>> \item
>>> -Finally, shared and exclusive locks are provided by the two functions
>>> -\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.
>>> +\hreplace{Finally, shared and exclusive locks are provided by the
>>> two functions
>>> +\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.}{Finally,
>>> shared lock
>>> +access is provided by the functions \mpifunc{MPI\_WIN\_LOCK},
>>> +\mpifunc{MPI\_WIN\_LOCKALL}, \mpifunc{MPI\_WIN\_UNLOCK}, and
>>> +\mpifunc{MPI\_WIN\_UNLOCK}. \mpifunc{MPI\_WIN\_LOCK} and
>>> +\mpifunc{MPI\_WIN\_UNLOCK} also provide exclusive lock capability. }
>>> Lock synchronization
>>> is useful for \MPI/ applications that
>>> emulate a shared memory model via \MPI/ calls; e.g., in a ``billboard''
>>> @@ -3499,7 +3503,11 @@
>>> update becomes visible in the public window copy. There is one
>>> exception to this rule, in the case where the same variable is updated
>>> by two concurrent accumulates that use the same operation, with the same
>>> -predefined datatype, on the same window.
>>> +predefined datatype, on the same window. \hcomment{Brian and Torsten
>>> think
>>> +that this is limiting the usefulness of the programming model
>>> +significantly, can we relax this (remove the ``same op'' restriction?
>>> +However, we have to be careful to still allow hardware optimizations of
>>> +subsets of operations only. Can this be done?}
>>> \item
>>> A put or accumulate must not access a target window once a local update
>>> or a put or accumulate update to another (overlapping) target window
>>> ---
>>>
>>
>>
>>
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>