We would like to discuss more fundamental issues concerning
the current treatment of threads in MPI than naming conventions.
During the last meeting one of us asked why MPI-2 document does not
contain any reference to a standard for thread packages
that can be used with MPI. It was answered that "people did not
like it" (does not explain much, huh?). However, referencing
such a standard is very important.
We think that MPI is supposed to provide a way to write PORTABLE
parallel programs. The only feasible option to provide a basis for writing
PORTABLE multi-threaded software with MPI is to refer
a standard for thread packages that can be used with
MPI. We are strongly convinced that MPI is not a vendor-specific (or
"group-of-vendor-specific") standard, and is not supposed to reflect
explicitly vendor-specific problems with thread packages or favor
any given thread package functionality (such as semantics of
synchronization primitives and thread management calls, scheduling
policies, interaction with signals, etc). However, it is reasonable to
allow users to specify if they are going to use multiple threads with
MPI, or they have a single-threaded application (since this allows for
obvious optimizations of MPI libraries). It is arguable how important it is
to do it at run-time, but it is not the point of this discussion.
We think it is quite clear by now that all this business with multiple thread support
options stems from the fact that some vendor thread libraries ARE NOT GOOD ENOUGH
to be used with a portable communication library (such as MPI). We are not
trying to deride anyone's system, but we don't think that this is a sufficient reason
to alter the MPI (vendor-independent and portable specification) to account for
idiosyncrasies of vendor-specific thread packages, many of which will disappear
over time, whereas MPI will (hopefully) remain fixed once standardized.
THE PROPOSAL FOR SECTION 7.8. "MPI and Threads".
We propose to state explicitly that MPI-2 considers ONLY POSIX-compliant
thread libraries for using to write PORTABLE multi-threaded MPI programs,
as well as multi-threaded MPI implementations (are there other standards for portable
thread packages? if there are, we are more than happy to compare them
and choose the best). (For VENDOR-SPECIFIC libraries - see below).
This will allow us to refer to the clearly specified model of interaction of threads inside
MPI implementation with user threads (calling or not calling MPI). This will also
provide portability of thread APIs, so one does not have to change the code
if two thread libraries provide similar functionality but different function names. In the
latter case, it suffices to write standard wrappers around native thread calls (trivial
exercise if the problem is only in different function names; however, if the functionality
of the two libraries is different to some extent, this will be more difficult).
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.
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.
The rest of the keys and values supply whatever relevant vendor-specific information
for an application to take advantage of (and comply with) vendor-specific features
and restrictions on using multiple threads with MPI. It is only natural to respectfully
ask vendors to provide exhaustive documentation on their thread packages and
MPI implementations to establish their competitive advantages over each other's
thread packages and MPI implementations.
In this way, we explicitly acknowledge that there is some diversity among existing
thread packages, but we can still provide an opportunity for PORTABLE multi-threaded
programming with MPI.
Other relevant MPI calls (such as MPI_Thread_Initialized) also should be changed
appropriately if our note concerning removing MPI_Thread_init is disregarded.
We would like to state it once again that without explicit reference to the
POSIX thread standard, MPI will be useless in multi-threaded
environments, and that the only honest alternative to referring to the
POSIX standard is just to say the interaction of threads and MPI is undefined,
(we strongly discourage the Forum from following this alternative, though, because
of the obvious advantages of multi-threaded programming models).
We earnestly hope that our proposal will be discussed in detail because of its importance.
Thanks for your time, see you at the April meeting.
Sincerely,
Boris Protopopov and Tony Skjellum.