Your right, the text must be written in a better way.
> I would prefer a cleaner solution, if at all.
No, I think this solution is really simple:
(Summary in 7 lines)
Non-blocking collective operations can be completed by an MPI_WAIT.
All test routines are also allowed but the application must
expect that they don't make any progress on the collective
operation and therefore always return false and then the
application must complete the request with MPI_WAIT.
MPI_WAITANY, MPI_WAITSOME, MPI_WAITALL and MPI_REQUEST_FREE
are not allowed.
Or in 5 lines, but I believe the 7 lines are better:
Non-blocking collective operations must not be completed by
MPI_WAITANY, MPI_WAITSOME, MPI_WAITALL or MPI_REQUEST_FREE.
The test routines need not complete a non-blocking collective
operation. Therefore the application must always call MPI_WAIT
if it makes no tests or gets only "false" test results.
And it is better than the current status ("at least" non-blocking
MPI_BARRIER that cannot be implemented efficiently on many systems).
And on systems without hardware-collective-support (e.g. on a
workstation or PC cluster) it might be an advantage for the
applications to have non-blocking collective operations like
REDUCE,...
Does there exist a better a solution?
I was not a member of the Coll-subcomitee, but I had to see,
that they always offered non-blocking collective operations
in the draft and at the last meeting they dropped them out
because they did not have a good solution for both, shared memory
and message-passing based systems.
Rolf
PS: In my original proposal I forgot to disallow also MPI_REQUEST_FREE.