Yes, I also do not like more subdivision than necessary,
but I do not want that any MPI implementation must name itsself
less thread-"compliant" than it is, i.e. I do not want that any
MPI implementation must name itsself wit "MPI_THREADS_NOT_SUPPORTED"
if it can support the usage of threads by the application in some
First to your final statement:
> In my opinion, there are only two choices:
> thread-safe MPI implemetation (MPI_MLTIPLE_THREADS) and
> non-thread-safe MPI implementaiton (MPI_THREADS_NOT_SUPPORTED)
> because if one uses MPI calls only in one thread, or if MPI calls
> occure in different threads but sequentially can be handled without
> problems by a non-thread-safe MPI implementation.
I want to remember on Eric Salo's Mail:
| Date: Wed, 5 Feb 1997 15:50:33 -0800
| > A related question: are there any impelementations where
| > multithreading is unsafe even when only one thread is making
| > MPI calls?
| Our 2.0 release suffered from this problem, but that has been fixed
| in 3.0 so it's a moot point.
For example a thread-based MPI-implementation that uses internally
pthread_barrier and an application that calls MPI only from the
main thread, but uses other threads and also pthread_barrier
may cause serious trouble because pthread_barrier does not
differentiate between different threads, it uses only a counter.
my case 1 and my cases 2&3:
: 1. MPI implementations that do not allow that the application uses
: 2. MPI implementations that allow that the application uses threads,
: but it expects that MPI calls are issued always from the main;
: 3. MPI implementations that allow that the application uses threads,
: but it expects that MPI calls are never called in a way that they
: run in parallel;
> Rolf, what are the implications on an MPI implementation that make the
> cases 2 & 3 different?
> I think, in both cases MPI calls are called sequentially. The fact
> that the calls are made from different threads (3) rather than from
> one thread (2) does not effect neither MPI implementations nor
Here I want to remember on Marc's Mail; he seems to see more problems
with 3 than with 2:
| 2. MPI implementations that allow that the application uses threads,
| but it expects that MPI calls are issued always from the main;
| MPI_THREAD_QUERY will return MPI_SINGLE_THREAD
| 3. MPI implementations that allow that the application uses threads,
| but it expects that MPI calls are never called in a way that they
| run in parallel;
| Hard to define in an accurate manner (since MPI activites can
| happen while the user makes
| no MPI calls). Also, of doubtful usage: if the user synchronizes to
| ensure mutual exclusion of MPI calls, it might as well have these
| calls executed by one thread: communication buffers are likely to be
| on the heap.
But I have problems with Marc's answer:
- To the answer to my case 2:
The actual proposal (10th Feb.) says that
MPI_SINGLE_THREAD == MPI library is thread compliant and ... (p.24:5)
thread-compliant: two concurrently running threads may make MPI calls
(p. 22 lines 5-7).
Therefore MPI implementations that support my cases 1-2 or 1-3 are
not allowed to name themself "MPI_SINGLE_THREAD".
Therefore I believe that the text must be changed.
- To the answer "doubtful usage" to my case 3:
The scenario I have in my mind makes
Therefore it does not belong to my case 2.
It does not call all MPI routines from the same thread, because
it generates and deletes the MPI-calling threads sometimes.
But I cannot imagine, that there is any MPI implementation that
fulfils case 2 but not case 3.
But there may be some chance for optimization if the application
only calls MPI routines from the main thread?
> Again, what's the difference between the cases (a), (b), and (c) below?
> a. the application says that it will use only the main thread;
> b. the application says that MPI calls are done always from
> the main thread;
> c. the application says that MPI calls are done never in parallel;
> d. the application says that it wants to issue MPI calls from all
> threads in parallel
They are the same categories than 1.-4., but for the purpose that
the application may say that it will use less thread-functionality
than possible with a given MPI implementation.
If there is no need to differentiate between 2/b and 3/c than we
can remove 2/b -- but not 3/c as currently done by Marc's text.
> Who cares which particular thread called an MPI call if all MPI calls
> are done sequentially?
Is there any vendor that must care about this?
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626