Marc's alternate proposal does not disallow simultaneous PUTs to the same
window from multiple processes. So, what would be the consequences if it did? I
claim that we would then have a GET/PUT model which could be explained with a
few simple rules:
1) A "shared" window lock allows read access to that window, either locally
with a load or remotely with a GET.
2) An "exclusive" window lock allows both read and write access to that
window, either locally with a load/store or remotely with a get/put.
3) Attempts to access a window without first obtaining the appropriate lock
And that's it! A few observations:
1) We no longer need to distinguish between global epochs and local epochs;
once you have the lock, you can do whatever you want to the window and the
semantics are well-defined.
2) We no longer need to overload MPI_Barrier() with additional coherency
3) Rolf points out that adding a lock to a window may block other processes.
However, it is already erroneous for multiple processes to PUT to overlapping
regions within a window. So if two processes wish to modify overlapping
regions, they will need some sort of mutual exclusion anyway. And if the
regions do not overlap, then the application can create a larger number of
4) High-quality implementations can now detect erroneous GET/PUT calls by
checking internally to ensure that the proper locks have been obtained.
I believe that this model does a very nice job of providing a useful,
easy-to-understand abstraction which can be implemented both efficiently and
simply. I therefore propose that we add these stricter lock semantics to Marc's
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-808 last Xon said, just firstname.lastname@example.org Mountain View, CA 94043-1389 before he died?"