Unfortunately, the decision to decide which library to link must be made before
(or during) the first call made to any one of the library functions. Since
MPI_THREAD_INIT can't be called until after MPI_INIT is called,
MPI_THREAD_INIT may not be able to decide which library to load.
I guess it would be possible to make a multi-layered approach and load an
'MPI startup' library and then delay until the first actual communication call is called
(MPI_SEND for instance) but this throws a wrench into MPI_INIT as
it has to provide all initialization for even the threaded environment, even
if it isn't needed. Plus, it may not be even that easy -- it may not be possible to
write MPI_INIT in such a way at all because too many things change between
the thread-safe version and the single-threaded version. Also, the call to
MPI_THREAD_INIT may not need to be called until after some communication
happens. In that case, the DLL has already been loaded and you can't
use MPI_THREAD_INIT. I guess this could be called 'erroneous behavior'
but I think limiting the creation of threads to being before any communication
occurrs may be too strict. I can easily see the need to be able to
dynamically create threads during the runtime of an MPI program depending
on the data used or something.
I would have plenty of headaches if I had to implement such a thing :-)
Things that others have stated:
- We could use MPI_THREAD_INIT in place of MPI_INIT.
- Threaded MPI libraries may not initialize so it requires the user to
know what to do and this is wrong. In the above strategy, this would
not work because the user may communicate before calling the