I suggest that "minimal effort" has nothing to do with it. The issue is whether
or not it is even *possible* to implement certain semantics on certain
architectures without requiring that the architectures be modified in some
major way (i.e. hardware-wise or OS-wise).
> The proposals to make get/put collective, require a barrier
> synchronization (with fence operation deleted) to complete transfer of the
> data, or cooperation of the process that owns the window that put/gets are
> targeting make Global Arrays and its MIMD applications virtually impossible
> to implement on top of this modified "1-sided" model.
>
> To realize the problem, please imagine a class of producer-consumer
> algorithms executed by processes A and B with the items produced/consumed
> in the window of process C (which is executing some other subtask
> and is unaware of the 1-sided coms targeting its window).
> [I tried to post this example before but my message was probably lost -
> I am on travel in Europe with limited access to Internet]
First, let me say that it is possible to do what you say here in my proposal,
as long as you are able to run another process (perhaps but not necessarily on
the same processor as C) which is aware of the 1-sided coms. If this is not
possible, then I would like to understand how you can implement the above where A,
B, and C are on different nodes of a Unix workstation network (or maybe, different
nodes of an SP2), with or without MPI. (Remember, no fair running another process
-- e.g. a daemon -- on the same processor as C.)
If you cannot implement GA on such an architecture, then perhaps GA is, in some
sense, architecture dependent? i.e. it requires that certain processes run in
a certain architecture? You then will not be able to implement it in an
architecture independent model -- which is what MPI is attempting to be.
Perhaps you think that it should not necessarily be possible to implement all of
the MPI semantics on every architecture? If so, then perhaps that is the issue
for discussion, so that we can start with a common frame. (May I suggest that
you start by deciding the kinds of architectures the various features *should*
be implementable on.)
-Dave
-- =============================================================================== David C. DiNucci | MRJ, Inc., Rsrch Scntst |USMail: NASA Ames Rsrch Ctr dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2 (415)604-4430 | Parallel Tools Group | Moffett Field, CA 94035