[Mpi3-rma] MPI3 RMA proposals in general

Douglas Miller dougmill at us.ibm.com
Wed May 26 12:59:54 CDT 2010

The problems have shown up particularly with MPI_Win_fence which has the
vague definition of an epoch, so after a fence one is not sure if more RMA
may be done under the fence or if a new synchronization type will be used.
Since the asserts are not mandatory and not widely used, they don't really
help because you have to cover the case where no assert was given. Then add
in passive-target and it creates a lot of corner-cases and race conditions.

Douglas Miller                  BlueGene Messaging Development
IBM Corp., Rochester, MN USA                     Bldg 030-2 A410
dougmill at us.ibm.com               Douglas Miller/Rochester/IBM

             Pavan Balaji                                                  
             <balaji at mcs.anl.g                                             
             ov>                                                        To 
             Sent by:                  "MPI 3.0 Remote Memory Access       
             mpi3-rma-bounces@         working group"                      
             lists.mpi-forum.o         <mpi3-rma at lists.mpi-forum.org>      
             rg                                                         cc 
             05/26/2010 12:49          Re: [Mpi3-rma] MPI3 RMA proposals   
             PM                        in general                          
             Please respond to                                             
              "MPI 3.0 Remote                                              
               Memory Access                                               
              working group"                                               
             <mpi3-rma at lists.m                                             

On 05/26/2010 12:45 PM, Douglas Miller wrote:
> But, what about having some restrictions on what synchronization that a
> window will use. I would envision either different window types
> (e.g. MPI_Win_create_lock, MPI_Win_create_pscw, ...) or at least some
> of assert parameter (which must be specified) to establish at cerate time
> how a window will be synchronized. At the very least then, internally I
> could add a function table to the window object that selected optimized
> routines based on the window usage.

Doug: MPI-2 has a restriction that two synchronization primitives cannot
be used simultaneously. So, that's a requirement from the application
side -- the MPI implementation should not have to maintain much state to
ensure this. So, I'm confused about how this would make the MPI
implementation better/faster. Can you clarify?

  -- Pavan

Pavan Balaji
mpi3-rma mailing list
mpi3-rma at lists.mpi-forum.org

More information about the mpiwg-rma mailing list