> A B
> put data window_wait(Wdata)
> window_post(Wdata) consume(data)
> window_clear(Wdata)
(I hope I got this indentation right----^^^^^^^^^^^^^^^^^^^)
>
>We intoduce a new synchronization operation:
>window_wait(comm, rank) blocks until the event associated with the window is
>set; window_post(comm, rank) sets the event, and window_clear(comm, data)
>clears the event.
This response has four main parts:
Observations and questions about the above "POST/WAIT" proposal;
General observations about all of the proposals so far;
Proposed extensions to the "PUT/ACCEPT" proposal to maintain desirable
qualities while adding some qualities in the POST/WAIT proposal;
Summary
For more generality, the rest of this message will assume three PUTs instead
of one in the above example.
Observations and Questions on the POST/WAIT proposal
====================================================
The new proposal sounds almost identical to the original proposal with
counters, if PUTs were made non-overtaking -- i.e. I believe that the above
would be the same as:
PUT data(incr=0)
PUT data(incr=0)
PUT data(incr=1)
counter wait
window_in
consume(data)
If the program did not know that the last PUT was indeed the last PUT before
it was executed, the proper "incr" argument could not be specified there. In
that case, the program may need to issue a separate empty PUT after all the
other PUTs are finished, just to increment the counter in the target. There
is no reason that this would be slower, however, than a "window_post".
Questions:
Q1. Does window_post block?
Q2. I assume that "window_clear" is needed to perform cache_flush
(WINDOW_OUT)? Otherwise, I'm not sure why it is needed. It
would seem more desirable to have each "window_post" increment
the signal count at the target (i.e. a "P" operation of a semaphore)
and "window_wait" decrement it if possible (i.e. a "V" operation on
a semaphore). However, if this was the case, then it appears that
window_post and window_clear would perform exactly the same operation
as sending and receiving a 0-length message.
Q3. Between a "window_wait" and a "window_clear", what happens to other
incoming signals? Are they lost or do they add up? Does window_clear
decrement the signal count, or zero it?
Q4. I suppose window_post and window_clear work for GETs, too. My first
guess is:
A B
produce(data)
window_post window_wait
GET from A
GET from A
GET from A
window_clear
But in the previous example, window_wait was like a WINDOW_IN and
window_clear was like a WINDOW_OUT. Here, window_post must act like
WINDOW_OUT, and window_wait and window_clear don't do anything, it seems.
Is it possible for these functions to know how to act from their context?
Do the GETs block, or are they satisfied only when the window_clear is
executed? Or, if I have this all mixed up, what is the proper way to
code this example?
General Observations on all Proposals
=====================================
There are at least four kinds of synchronization which can be found in one or
more of the proposals:
(S1) Synchronization to allow the target to prevent PUTs or GETs from
occurring before they are desired. [Only in PUT/ACCEPT proposal.]
(S2) Synchronization to allow the target to count the number of PUTs or
GETs which have occurred. [In both the original proposal, with
counters, and PUT/ACCEPT proposal.]
(S3) Synchronization to allow the originator to explicitly signal the
target when all PUTs or GETs have occurred. [In both the original
proposal with counters, if PUTs and/or GETs are guaranteed to be
non-overtaking, and this new POST/WAIT proposal.]
(S4) Synchronization to prevent multiple processes from performing
simultaneous operations to the same window, or (viewed differently)
to allow a single process to combine separate PUTs or GETs into a
logically-atomic composite operation. [In Marc's LOCK/UNLOCK
alternate proposal.]
The first three may be important, although S2 could be considered as a special
case of S3. I do not yet understand when S4 might be desirable, but if it is,
I think that it is different enough from the others that it can be handled
separately.
Of course, messages and barriers can be used instead of any synchronization
built into the models, provided adequate precautions are taken, but time can
sometimes be saved by performing the synchronization with the PUTs and GETs
themselves.
[Aside: The observation in Q2 shows me that the PUT/ACCEPT proposal can
technically already handle the S3 synchronization in the new
POST/WAIT proposal, by replacing each "window_post" with a "SEND(nputs)"
and each "window_wait" with a "RECV(nputs)", then executing an
"ACCEPT(nputs)" on the target: e.g. the running example becomes:
A B
PUT data
PUT data
PUT data
SEND(B,3) RECV(A,nputs)
ACCEPT(0) ACCEPT(nputs)
consume(data)
This, however, has the unfortunate property that (as Eric would say) "bits
aren't moving" until process B receives the message.
End of Aside.]
Proposed Extension to PUT/ACCEPT Proposal
==========================================
My previous PUT/ACCEPT proposal can be modified in the following way to add
the functionality present in this new POST/WAIT proposal (i.e. S3, above)
without losing previous functionality (specifically, S1 above). In doing
so, this will lessen the circumstances where the user will need to use the
collective operations ACCEPTC and OFFERC, since these will necessarily be
less efficient than their non-collective counterparts.
Modification #1: Allow the user to specify an "incr" argument for the PUT
and GET routines (similar to the original chapter 4 proposal), and have
ACCEPT and OFFER count these increments for matched PUTs and GETs instead
of the PUTs or GETs themselves. The value supplied for an "incr" argument
must be either 0 or 1. An "incr" will only have an effect in the target
if all previous PUTs or GETs with the same communicator and tag have been
performed (already guaranteed by existing non-overtaking semantics in the
proposal).
The running example becomes:
A B
PUT data(incr=0) ACCEPT(1)
PUT data(incr=0)
PUT data(incr=1)
ACCEPT(0) consume(data)
Modification #2: (Syntactic sugar: can be dropped without affecting #1 above)
Instead of explicitly providing the "incr" argument, I suggest that
two different GET operations -- e.g. GET and GETHOLD -- and two different
PUT operations -- e.g. PUT and PUTHOLD -- be provided, which have
identical functionality except that the first in each class (i.e. GET or
PUT) would have an implied incr of 1 and the latter in each class (i.e.
GETHOLD or PUTHOLD) would have an implied incr of 0.
The running example becomes:
A B
PUTHOLD data ACCEPT(1)
PUTHOLD data
PUT data
ACCEPT(0) consume(data)
Summary
=======
I think that this proposal combines all of the best aspects of my proposal and
Marc's proposals -- i.e. all three types of synchronization above (S1,S2, and
S3). If there is a need to add the fourth type of synchronization (i.e. S4,
the LOCK/UNLOCK synchronization), it could be added with little change from
Marc's initial proposal.
The PUT/ACCEPT proposal is very similar to standard message-passing, except
that one side specifies the locations and type of the message on both the
originator and the target, as the "1-sided" name suggests.
This PUT/ACCEPT proposal still does not facilitate 3rd-party communication
or efficient polling, which some of the other proposals may still support.
However, I claim that
* polling can always be made unnecessary for 2-party communications by
proper use of the constructs in the PUT/ACCEPT proposal, and
* 3rd-party communications can be facilitated, for those applications
that need them, by allowing the user to build a simple agent and using the
constructs within the PUT/ACCEPT proposal to perform 2-party
communications with the agent. This removes the requirement (which is
present in all proposals supporting 3rd-party communication) for some
architectures to have an agent (daemon) running at all times -- even for
those many cases where 3rd-party communication is not used.
-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