1. Can we imagine that implementors want to deliver two different
libraries:
- a fast, but not thread compliant
- a less fast, but thread compliant
And can we imagine that the first one may support
MPI_SINGLE_MPI_THREAD or even MPI_NO_CONCURRENT_MPI_CALLS?
Yes?
Then we should relax a little bit on the text page 4, lines 16-22
that knows only libraries that are full thread compliant
or that always return provided=MPI_SINGLE_THREAD.
======================================== line 21-22
I would propose to remove the 4 chars "E.g." on line 21 and to
add the sentence after line 22:
"and libraries with an intermediate support level may return
this -- or a required less strict -- level in 'provided'.
In general the value returned in provided is independent of
the value required."
2. Would it be a good idea to additional define the following
C pre-processor (cpp) macros:
In the include file mpi.f the following macros are defined if
the equivalent thread requirement -- or a stricter one --
is supported:
MPI_SUPPORT_SINGLE_THREAD
MPI_SUPPORT_SINGLE_MPI_THREAD
MPI_SUPPORT_NO_CONCURRENT
MPI_SUPPORT_MULTIPLE_THREADS
E.g. if MPI_SUPPORT_NO_CONCURRENT is defined then a call to
MPI_THREAD_INIT with required=MPI_NO_CONCURRENT_MPI_CALLS,
MPI_SINGLE_MPI_THREAD or MPI_SINGLE_THREAD will return in
'provided' never a less strict thread support level than
required.
And e.g. if MPI_SUPPORT_NO_CONCURRENT is not defined then
MPI_THREAD_INIT will never return
provided=MPI_SUPPORT_NO_CONCURRENT
or MPI_SUPPORT_MULTIPLE_THREADS.
This little amendment would simplify compile-time decisions.
The current proposal supports only run-time decisions.
The implementation effort should be minimal, because only
1-4 additional lines in mpi.h are needed.
Is this a good idea?
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de