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-propos...

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