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."
***
I shall put text to make clear that "thread compliant" is not
necessarily a static
characteristic of an implementation, but may be dynamically altered,
e.g., by
arguments to mpiexec. The user may specify that he/she does not intend
to use
threads, in which case, another library is linked (statically, if need
be).
In such a case, the MPI environment is deemed not to be "thread
compliant", and the
system may refuse to honor a required=MPI_MULTIPLE_THREADS
****
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?
****
No, this is a bad idea if we want to leave open the option of specifiying
the level of thread
support required at link/load time. Static macros in mpi.h will be
misleading.
*****