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

[Pavan Balaji]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: one-side-2.pdf
Type: application/pdf
Size: 550243 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20110122/9c813593/attachment-0001.pdf>