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

[Rajeev Thakur]

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-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
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma