On Mar 4, 2010, at 7:36 AM, Richard Treumann wrote:
> A call to MPI_Init allows the MPI library to return any level of
> thread support it chooses.
This is correct, insofar as the MPI implementation can always choose
any level of thread support.
> This MPI 1.1 call does not let the application say what it wants and
> does not let the implementation reply with what it can guarantee.
Well, sort of. MPI-2.2, sec 12.4.3, page 385, lines 24-25:
24| A call to MPI_INIT has the same effect as a call to
MPI_INIT_THREAD with a required
25| = MPI_THREAD_SINGLE.
So even though there is no explicit request and response for thread
level support, it is implicitly asking for MPI_THREAD_SINGLE. Since
all implementations must be able to support at least SINGLE (0 threads
running doesn't really make sense), SINGLE will be provided at a
minimum. Callers to plain-old "MPI_Init" should not expect any higher
level of thread support if they wish to maintain portability.
> Consider a made up example:
> Imagine some system supports Mutex lock/unlock but with terrible
> performance. As a work around, it offers a non-standard substitute
> for malloc called st_malloc (single thread malloc) that does not do
Dick's example is a great illustration of why FUNNELED might be
necessary. The moral of the story is "don't lie to the MPI