I suggest the following text as an alternative to page 107, lines 16-36:
All persistent requests for collective operations can be started
without blocking with MPI_START.
The non-blocking collective operations have a very restricted
progress rule:
The progress of non-blocking collective operations is
guaranteed only when all involved processes have issued a MPI_WAIT.
Rationale.
On some systems a barrier and shared memory based execution of
collective operations may be much faster than a message passing
based execution. Therefore on such systems MPI allows to implement
non-blocking collective operations by using the blocking ones
inside of MPI_WAIT. It is also allowed to implement non-blocking
collective operations in a way that progress is done as soon as
all involved processes have started the operation.
End of rationale.
Advice to uses.
A portable application must not complete a non-blocking collective
operation by a call to MPI_WAITANY, MPI_WAITSOME, MPI_WAITALL and
MPI_REQUEST_FREE. The test routines need not complete a non-blocking
collective operation. Therefore a portable application must always
call MPI_WAIT if it makes no tests or gets only false test results.
End of advice to users.
Discussion.
I think this proposal fulfills all the requirements discussed
at the last forum:
- it allows non-blocking implementation (on message-based systems)
- it allows blocking implementation (on syst. with hardware support)
- it gives the user a hint that he/she should not expect that it
is implemented in the background
- it is compatible to MPI 1.1 because MPI 1.1 defines in
3.7.4 "Semantics of Nonblocking Communications" only
"Progress" rules for nonblocking receive and nonblocking send,
but no general rule for nonblocking communication at all.
- a non-blocking implementation allows the parallelisation
of computation and collective communication
(This is most of that the user wants).
- only the overlap of different non-blocking operations is
restricted by this definition. (This is a marginal problem
compared with not allowing a blocking implementation).
- for the user it is better to have this restricted form than
to have nowhere the chance to overlap computation and collective
communication.
- the users does not need first an "Ibarrier", but they need
first the non-blocking bcast, reduce, scatter and gather
functions.
For these reasons this porposal makes more sense than the actual
draft.
Is this now a proposal that can be voted positive?
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de