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

[Barrett, Brian W]

Pavan -

Before you commit, it would be good to get some favorable reviews.

I'm having some trouble figuring out what you merged in from Torsten's document - I can see the purple removes, but given that there was already a bunch of red and dark red, it's a bit difficult to pick out the additions.  Would it be possible to either pick a different color for your additions, merge into Torsten's clean document, or list all the changes?

Brian

On Jan 22, 2011, at 2: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
>> ---
>> 
> 
> -- 
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> <one-side-2.pdf><ATT00002..txt>

--
  Brian W. Barrett
  Dept. 1423: Scalable System Software
  Sandia National Laboratories