Several examples (11.12, 11.14, 11.15, 11.16) demonstrate the lockless synchronization mode. Does that still exist? MPI_Accumulate has a couple of sentences that specify that only predefined ops are allowed. That text is missing in MPI_Get_accumulate and MPI_Fetch_and_op. Rajeev On Jan 19, 2011, at 9: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 ---
-- 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 _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma