comm: beef up use of PMIx_Group_construct #12960
Conversation
to avoid potential race conditions between successive calls to MPI_Comm_create_from_group and MPI_Intercomm_create_from_groups when using the same tag argument value. The PMIx group constructor grp string argument has different semantics from the tag requirements for these MPI constructors, so use discriminators to avoid potential race conditions when using PMIx group ops. Related to open-mpi#10895 Signed-off-by: Howard Pritchard <[email protected]>
|
Hmmm...I must be missing something. I applied your patch to the head of OMPI main and ran Jeff's program from #12906, but I'm not seeing this revised PMIx group ID being constructed anywhere, and the program still hangs. |
|
sorry that PR is not directly to this issue. we have two problems - one is the race case in mpi4py when using pmix groups (that's what the PR #12960 is for), then there's this one. so it was somewhat of a mistake to say this issue is related to that pr. i'm looking at this one as well but i suspect the fix will be in a totally different place as the spawn operation uses totally different pmix functionality. |
|
well i thought i was updating the issue and not my pr. so the text above is more for issue #12906 |
|
😄 Got it - thanks for the explanation! |
hppritcha
requested review from
bwbarrett and
edgargabriel
and removed request for
bwbarrett
to avoid potential race conditions between successive calls to MPI_Comm_create_from_group and MPI_Intercomm_create_from_groups when using the same tag argument value.
The PMIx group constructor grp string argument has different semantics from the tag requirements for these MPI constructors, so use discriminators to avoid potential race conditions when using PMIx group ops.
Related to #10895