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

Torsten Hoefler htor at illinois.edu
Wed Jan 19 21:51:32 CST 2011


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

-- 
 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler         | Performance Modeling and Simulation Lead
Blue Waters Directorate | University of Illinois (UIUC)
1205 W Clark Street     | Urbana, IL, 61801
NCSA Building           | +01 (217) 244-7736



More information about the mpiwg-rma mailing list