This functionality will be in MPI, no matter which of the current options is
voted in. The only debate on this is which approaches are (1) easier to
understand, and (2) more efficient in the sense that more processors can keep
busy doing useful work.
> Why are people proposing radical changes to a chapter that has already
> passed the first formal vote? Could it be that there is a profound
> lack of confidence in what we are doing? I understand the vote was 13-7-5.
I did some analysis of the current proposal last weekend (prompted by a remark
from Eric Salo), and found that some parts of chapter 4 did not seem well defined.
Requests for clarification did not seem to be fruitful. So, after removing the
problem parts (i.e. WINDOW_IN, WINDOW_OUT, FENCE, and counters), the rest of the
proposal was simplified. This was called the Barrier-based model. Then I
simplified it some more to make GET and PUT collective operations. Both of these
proposals will handle your problems, above, without WINDOW_IN, WINDOW_OUT, FENCE,
or counters. Some people seem to be objecting to the collective operations, even
though I assert that they are *at least*, and in some cases, *more* efficient and
easier to understand than the barrier-based one.
However, both of these leave some functionality out -- specifically, how to just
have two (or a few) processes in a communicator performing GET and PUT, and/or
performing operations through a third process (similar to what Jarek is
addressing). I proposed one solution (see "Extended Proposal: pt2pt 1-sided"),
Marc proposed another just now, and others are considering others. There are a
few other issues, too, such as whether the target process is required to leave
its entire address space open to GETs and PUTs, or whether it can restrict the
portions visible/modifiable by other processes. (For the record -- I'm on the
side of restriction.) Nothing else too important.
(The history according to Dave.)
-- =============================================================================== David C. DiNucci | MRJ, Inc., Rsrch Scntst |USMail: NASA Ames Rsrch Ctr firstname.lastname@example.org| NAS (Num. Aerospace Sim.)| M/S T27A-2 (415)604-4430 | Parallel Tools Group | Moffett Field, CA 94035