[Mpi3-rma] MPI3 RMA proposals in general
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
<balaji at mcs.anl.g
Sent by: "MPI 3.0 Remote Memory Access
mpi3-rma-bounces@ working group"
lists.mpi-forum.o <mpi3-rma at lists.mpi-forum.org>
05/26/2010 12:49 Re: [Mpi3-rma] MPI3 RMA proposals
PM in general
Please respond to
"MPI 3.0 Remote
<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?
mpi3-rma mailing list
mpi3-rma at lists.mpi-forum.org
More information about the mpiwg-rma