Tags are added to two-phase collective operations
in order to permit multiple two-phase operations per
communicator.
Matching is accomplished in two-phase operations by
communicator, type-of-operation, and user tag.
Wildcards are prohibited in the collective tags.
Advice to implementors.
For systems that implement collective on top of point-to-point,
this poses no special penalty. For systems that propose to
use hardware for collective, I suspect there can be objections,
but these same objections apply to overlapping groups posing
non-blocking collectives as well, or any case where the special
hardware must be multiplexed between activities.
The space of tags may be more proscribed than for point-to-point,
in order to allow implementations to encode other needed bits
involving the type of operation.
End advice to implementors.
Rationale.
Tags were dropped from non-blocking collectives a while ago,
mostly because Marc argued that this was an asymmetry from
blocking collectives. We have agreed to have a totally
different non-blocking strategy for collectives now, which
is also unanalogous to the request approach of non-blocking
point-to-point. Hence, the compelling use of "symmetry" to
eliminate tags is no longer compelling at all.
Tags also solve the problem of multithreaded operations using
collectives, inasmuch as they permit the threaded program to
assert the ownership of on-going non-blocking collectives per
thread.
By adding tags to the two-phase collectives, we permit threading,
and multiple uses per communicator in single threaded programs.
End Rationale.
Advice to users.
Use unique tags in two-phase collective communication operations
when multiple operations per communicator are needed, or when
writing multithreaded programs that share a communicator.
The tags need only be unique for each type of operation used.
That is, tag=5 for reduce, and tag=5 for bcast will not interfere,
when posed in two-phase form.
End advice to users
Discussion
Collective tag ranges might be smaller than for point-to-point.
An appropriate environmental inquiry function would be needed.
End Discussion
Anthony Skjellum, PhD, Associate Professor of Computer Science;
Mississippi State University, Department of Computer Science & NSF ERC
Butler, Rm 300, PO Box 9637, Corner of Perry&Barr, Mississippi State,MS 39762
(601)325-8435 FAX: (601)325-8997; http://www.erc.msstate.edu/~tony;
"Persistence is fertile." ; e-mail: tony@cs.msstate.edu; Try MPI!