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

Pavan Balaji balaji at mcs.anl.gov
Sat Jan 22 16:58:26 CST 2011

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

Pavan Balaji

More information about the mpiwg-rma mailing list