There are still a few problems, though.
1) The system may not maintain a group leaders sequence number, but
rather may only ensure the spatial uniqueness of the "local id",
rather than its temporal uniqueness too. In other words the local
context id is re-used, so two communicators which do not exist at the
same time may well have the same local context id and group
leader. (I do this in the Meiko MPICH implementation...)
Therefore generating the absolutely unique communicator id which
people seem to want will require more work in the implementation (at
each communicator creation operation the group leader will need to
increment a sequence number and broadcast it), which is not currently
required. Thus the current proposal has an additional cost...
2) To ensure the uniqueness of the "group leader", "local context id",
you must combine them in a way which loses no information. Therefore
the total number of bits you need in the result (the unique tag) must
be the sum of the numbers of bits in each of the inputs.
Suppose you have 8K Processes (== 13 bits), that leaves 29 bits for
the local id (2**29 == 536,870,912). This would run out after 90
minutes if you churn communicators once every 10uS.
I suppose the real point from this is that you *cannot* require that
the communicator id be temporally unique, since you can always (by
running longer and creating more communicators) require more bits than
are available in the result.
-- Jim
James Cownie
Meiko Limited Meiko Inc.
650 Aztec West 130C Baker Avenue Ext.
Bristol BS12 4SD Concord
England MA 01742
Phone : +44 1454 616171 +1 508 371 0088
FAX : +44 1454 618188 +1 508 371 7516
E-Mail: jim@meiko.co.uk or jim@meiko.com
WWW : http://www.meiko.com/welcome.html