> We propose to state explicitly that MPI-2 considers ONLY POSIX-compliant
thread libraries
....
*****
We have never said in the past that MPI-2 considers only ANSI C or only
standard complinat implementations of Fortran, and so on. I don't think it
is our business to discuss what flavor of threads a system supports, how
threads are created, how they synchronize, etc. It is our business to
discuss only how MPI calls interact with threads. I see no reason why SUN
would not offer MPI with Solaris threads, rather than POSIX threads if they
wish to do so; or MPI with NT threads. In fact, an important case where
MPI will interact with threads is when the threads are created by a
parallelizing compiler. In such a case, the programmer sees no thread
syntax at all; it only needs to initialize MPI to work with threads.
******
> We don't like the MPI_Thread_init call since it separates
multi-threaded programs from single-thread. All systems we know
of actually require specifying at link time whether the thread-safe system
libraries are used. So, what's the point to postpone till run-time the
decision concerning which MPI library (thread-compliant or not) to link?
Moreover, using separate functions for thread-compliant and single-threaded
MPI initialization makes users require to know whether the third-party
libraries they use have multiple threads or not. We think this is wrong.
****
First, for AIX, and I assume for most, if not all, systems that support
dynamic linking, the decision of which library to link to may be delayed
to run-time. Thus, an implementation may have two different MPI libraries,
and pick which one to use only when MPI_THREAD_INIT is called.
Second, the proposal does not require users to use different functions for
thread-compliant and single-threaded MPI: We require MPI_Thread_init to be
supported by all MPI implementations, whether thread compliant or not.
MPI_Thread_init will be used for initialization in all cases (function name
may be wrong, but that's another story).
Third, the proposal does not prevent implementors to provide a link time
switch that allows the user to specify whether he/she needs threads. As
usual, the syntax of link time switches is implementation dependent. If the
user specified at link time that he/she will not use threads, then
MPI_Thread_init may not be capable of honoring
required=MPI_MULTIPLE_THREADS, and may return provided=MPI_SINGLE_THREADS.
Fourth, we either say that MPI always run in an environment that supports
threads, or we accept the fact that third party libraries have to deal both
with single threaded and multi threaded environments. I think the later is
more realistic. In fact, there will be more information that a third party
library will be after. If one cares about performance, one might want to
have a hint about the "right" multiprocessing level; one may want to reuse
in the library code threads that were spawned outside the library (a
"loosely synchronous" parallel invocation model), in which case one needs
to know the number of such threads; and so on.
***********
If the MPI_Thread_init is dropped, an inquiry function is necessary to
determine later (for instance, in a portable library code that uses MPI)
which type of the MPI environment is there.
Nevertheless, our idea can be illustrated with the MPI_Thread_init call
also. We propose to change the call as follows:
int MPI_Thread_init (int required, int* provided, MPI_Info* info)
"required" and "provided" take the following values:
MPI_SINGLE_THREAD - single-thread MPI implementation
MPI_MLTIPLE_THREADS - multi-thread MPI implementation with the
functionality
guaranteed by the POSIX thread
standard
MPI_VENDOR_SPECIFIC - does not provide full-fledged POSIX functionality
(or maybe gives some extra
features)
If MPI_VENDOR_SPECIFIC in specified in the "required", the appropriate
vendor should be given in the VENDOR field of the MPI_Info argument.
The "info" argument contains a standardized key - VENDOR_PACKAGE - and
a value that takes appropriate values such as:
NOT_SUPPORTED - returned if the requested vendor package is not
supported
by the MPI implementation
SOLARIS_THREADS
WINNT_THREADS
IBM_THREADS
SGI_THERADS
HP_THREADS, etc.
****
Unless I miss something, this proposal makes no sense: Different thread
packages have
different syntax. One can select at run time library A, rather than
library B, when
both have the same interface, but one cannot specify at run-time whether
the code will
use solaris threads or NT threads.
By the way, IBM supports POSIX pthreads only.
Marc
*****