[mpich2-dev] Does MPI_WIn_unlock() need a reply?

[Rajeev Thakur]

David,
           For passive-target RMA, the target needs to call MPI_Win_lock
before it can access its local window memory that may have been updated by a
Put from a remote process. This may not be obvious from a quick glance at
the Standard (nothing is in the one-sided chapter :-)), but it is covered by
item 6 of Section 6.7 on Semantics and Correctness (pg 138 of the pdf
version). Also see lines 32-37 on that page. The update done by the remote
process may not be visible to the target process until it calls
MPI_Win_lock.
 
The implementation of MPI_Win_unlock in MPICH2 is also described in the last
para on pg 10 and 1st half of pg 11 of the paper
http://www-unix.mcs.anl.gov/~thakur/papers/ijhpca-rma.pdf, but we neglected
to remind readers of the above requirement of the Standard.
 
Rajeev


  _____  

From: owner-mpich2-dev at mcs.anl.gov [mailto:owner-mpich2-dev at mcs.anl.gov] On
Behalf Of David Gingold
Sent: Monday, March 03, 2008 3:48 PM
To: mpich2-dev at mcs.anl.gov
Cc: Larry Stewart
Subject: [mpich2-dev] Does MPI_WIn_unlock() need a reply?


MPICH2 developers -- 

I've been looking at the ch3 implementation of MPI_Win_unlock(). It makes
some effort to determine whether it needs to see a message from the target
indicating that the RMA is complete on that end. In one case, the code
concludes that if the lock operation was exclusive then there is no need to
wait for a reply.

My MPI book says, of MPI_Win_lock(), "RMA operations issued . . . will have
completed both at the origin and at the target when the call returns."

I think I see the argument that the MPICH2 optimization is okay -- if it's
an exclusive lock, nobody else will be able to get a lock before the unlock
completes at the target. But what about something like this:

1. A locks a window at B, exclusively.
2. A initiates a put to the window at B. The put completes at A, but not yet
at B.

3. A unlocks a window at B (but waits for no reply)

4. A indicates to C that A completed its access to B's window

5. C indicates to B that A has finished A's access

6. B access its window's memory, but before the put completed at its end.


It's a bit of a stretch, yes. Is it plausible?

-dg


--
David Gingold
Principal Software Engineer
SiCortex
Three Clock Tower Place, Suite 210
Maynard MA 01754
(978) 897-0214 x224




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mcs.anl.gov/mailman/private/mpich2-dev/attachments/20080303/88e42800/attachment.htm>