> I'm having some trouble understanding the new proposal for
> using MPI-2 in multithreaded environments.
> First, if an MPI implementation without thread support does
> not need to provide even dummy versions of MPI_OK_Threads
> and MPI_Thread_enabled, how can the example programs shown
> be compiled for these implementations?
Ok, this is a good point. I was trying to avoid dummy type routines
but clearly it won't work. I'm not sure what the dummy routine should
do. Should it look the same and be a noop? Maybe generating an error
is a good idea? I am open on this one.
> Second, I don't understand why both MPI_Thread_enabled and
> MPI_OK_Threads are necessary. If I understand the descriptions
> correctly, the only case where one function could return true
> and the other false is when some thread can call MPI but the
> current one can't. In the example, this is shown as
> happening after an implementation has reported that it
> supports threads. Is it meaningful for an MPI implementation to
> claim that it supports threads when it really only supports
> one thread calling MPI? Or will there be implementations where
> more than one but fewer than all the threads can call MPI?
The reason I put in two functions was to distinguish the following.
1) You want to see if you can spawn threads to do MPI. Checking
MPI_OK_THREADS will do this. Checking MPI_THREAD_ENABLED will not
tell you this since you may be allowed to do MPI on this thread but
not others. This can happen even if MPI_HAS_THREADS is true if
MPI_USE_THREADS is not called.
2) MPI_HAS_THREADS is true, MPI_OK_THREADS is false, and the program
is running in a multi-threaded environment. You want to know if the
current thread is the one the called MPI_INIT since it is the only
thread that can do MPI calls. To do this you must check the current
thread with MPI_THREAD_ENABLED.
Basically, the description John gives is correct. The hard one is the
situation where MPI supports threads but this is not enabled (with
MPI_USE_THREADS). This was viewed as an important case since many
future implementations will support threads but doing so will reduce
performance due to locks, etc. If MPI knows that even though it
supports threads only one will ever make MPI calls then it can avoid
the locks. In this case, there may be lots of threads but the user
only has one to make MPI calls. A library could get called on a
different thread and not know it cannot make MPI calls. That is what
MPI_THREAD_ENABLED adds - the ability to catch this.
Thus, the need for the two functions. It may be possible to do with
less or give up some checking ability in user code.
> A related question: are there any impelementations where
> multithreading is unsafe even when only one thread is making
> MPI calls?
I don't recall having heard of one but I don't know for sure.