> Lloyd already pointed out that the idea is, that the start call is
> non-blocking, and that only the end-call may block. (i.e. no step
> backwards)
My reading was that Lloyd pointed out the options here, and we haven't
yet taken the decision.
Since at least one of the calls must be collective the options are
Start End
1) collective local
2) local collective
3) collective collective
Option 1 gives you nothing beyond what you already have, so can be
ignored.
Option 2 is what Lloyd appears to be proposing.
Option 3 is what the text currently says.
I actually prefer option 3 (both start and end are collective).
It has the following benefits :-
1) A legal implementation of these functions is to replace them with
the existing blocking functions at start time, when all the
arguments are known.
2) It provides a way for the implementation only to allocate the
resources required for these operations at the time the first such
operation is performed in a communicator. (Resource allocation is
assumed to require collective communication).
3) (As a result of 2) It allows an easy extension to the draft which
is to permit multiple outstanding such operations in a communicator.
To expand on the possibility of multiple operations :-
1) We would allow an arbitrary number of two-phase collective
operations in a communicator.
2) They must be strictly nested.
3) They must occur in the same order in each member of the
communicator.
Because the implementation can block to allocate the necessary
resources in the start operation, it need not allocate any resources
to communicators as it creates them, rather it can allocate these
(scarce) resources only to the communicators which require them. Since
it is now dynamically allocating these resources it is a relatively
simple extension to allow multiple such operations in a single
communicator.
Note that this proposal does *not* include tags in the collective
operations, these would only be required if we wanted to relax the
ordering rule (rule 3) above. I see no reason to do that. (For
instance Rolf's application example didn't need it). Adding tags would
remove the possibility of implementing these operations using the
existing, blocking collective operations.
In this version these operations really become hints to the
implementation that the user would like things to happen
asynchronously, however there is no requirement on the implementation
to work that way.
-- Jim
James Cownie
Dolphin Interconnect Solutions
Phone : +44 117 9071438
E-Mail: jcownie@dolphinics.com