ompi: always enable MPI_THREAD_MULTIPLE support #1397
Conversation
This commit removes the --with-mpi-thread-multiple option and forces MPI_THREAD_MULTIPLE support. This cleans up an abstration violation in opal where OMPI_ENABLE_THREAD_MULTIPLE determines whether the opal_using_threads is meaningful. To reduce the performance hit on MPI_THREAD_SINGLE programs an OPAL_UNLIKELY is used for the check on opal_using_threads in OPAL_THREAD_* macros. This commit does not clean up the arguments to the various functions that take whether muti-threading support is enabled. That should be done at a later time. Signed-off-by: Nathan Hjelm <[email protected]>
|
@bwbarrett Do you remember why the checks for OMPI_ENABLE_THREAD_MULTIPLE were left in opal/thread/mutex.h? @jsquyres, @bosilca, @rhc54, @gpaulsen This is the PR proposed on 2/23 at the developer meeting. The hit of this change is minimal on x86 but should be verified on power. |
|
:bot:retest: |
|
@nysal - We don't yet have Power 8 setup for Jenkins testing. Do you mind checking? |
|
I think we were worried about the performance impact, but I honestly don't remember. Whatever it is, seems not worth it if MPI_THREAD_MULTIPLE is the default... |
|
This patch completely removes the non thread-safe case, which, based on my understanding of the outcome of the discussion at the developer's meeting, is an extension of what we were originally looking for. |
|
@hjelmn Is this PR ready to go? |
This commit removes the --with-mpi-thread-multiple option and forces
MPI_THREAD_MULTIPLE support. This cleans up an abstration violation
in opal where OMPI_ENABLE_THREAD_MULTIPLE determines whether the
opal_using_threads is meaningful. To reduce the performance hit on
MPI_THREAD_SINGLE programs an OPAL_UNLIKELY is used for the
check on opal_using_threads in OPAL_THREAD_* macros.
This commit does not clean up the arguments to the various functions
that take whether muti-threading support is enabled. That should be
done at a later time.
Signed-off-by: Nathan Hjelm [email protected]