[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

Pavan Balaji balaji at mcs.anl.gov
Wed Aug 28 04:37:20 CDT 2013


Brian,

On 08/27/2013 10:35 PM, Barrett, Brian W wrote:
> Perhaps implementation-defined is the wrong word.  I'm not sure I agree
> with keith's undefined fright, but perhaps platform-defined?  There's a
> big difference between a replacement for MPI_WAIT and a memory barrier in
> a loop.

The comparison here should be a platform-specific memory barrier in a 
loop vs. MPI_WIN_SYNC in a loop.

My concern with "platform-defined" is that we are assuming that there is 
exactly one way of doing this for a given platform, which is known to 
the MPI implementation and to the user.  That is mandating something on 
the implementation and makes me uncomfortable.

"Implementation-defined" is better, in that the implementation is free 
to do whatever it wants.  The user can do the same thing if she knows 
what the implementation does.  But practically, there's likely no 
difference implementation-defined and undefined.

Can you also clarify which of the two items below is the real concern 
here (or both?):

1. Is it the cost of the MPI_WIN_SYNC function call?  If yes, how about 
we deprecate/remove PMPI_WIN_SYNC?  That way, MPI_WIN_SYNC can be a 
macro and truly a no-op on some platforms, so the concern that it might 
be expensive will go away?

2. Is it the fact that I have to do some additional call even on 
platforms where it is not needed (e.g., x86)?  So basically you want to 
do this:

P0:
Win_lock_all
Put(X)
Flush
Send

P1:
Win_lock_all
Recv
/* No Win_sync here */
read X

>> Also, I think we are ignoring the point Jim raised: does OpenSHMEM
>> really need these semantics?
>
> I think this is a grey area of OpenSHMEM and my belief is that it really
> does need those semantics.

Perhaps this is just an oversight in OpenSHMEM and can be fixed?

  -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji



More information about the mpiwg-rma mailing list