Oops!
Rolf, you are absolutely correct. Thanks for pointing this out.
> PS: This problem arises 5 minutes after I really thought that
> I will vote for the alternative.
Fortunately, I think I have a solution, so let's see if I can bring you back
over to the side of Goodness again...
Let's eliminate the locks entirely and instead bring back MPI_RMW. At least,
let's bring back the version that I proposed a few weeks back as a replacement
for the current one:
MPI_RMW(inval, outval, op, rank, comm)
This actually looks a lot like the lock functions, in that it takes both a rank
and a communicator. The semantics are that MPI_RMW has the effect of a fence
between the caller of the function and the owner of the window, which is
exactly what we were doing when we released the locks anyway.
So, in your example, we would have the following:
origin target
------ ------
put do {
rmw(&outval, OP_READ)
rmw(OP_INCREMENT) } while (outval == 0)
/* wait for target */ /* consume data */
compute()
do {
rmw(&outval, OP_READ) /* inform origin that buffer is free again */
} while (outval == 1) rmw(OP_INCREMENT)
/* begin next iteration, etc. */
In this model, the target does now know when the data is available for use.
This should also address Karl's concern about slow polling, I think, because
calls to atomically read the rmw value of a local window should be very fast.
For those who prefer barrier semantics, those still work exactly as they do in
Marc's alternate proposal.
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-808 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"