[Mpi3-hybridpm] MPI_THREAD_SINGLE

[Jeff Hammond]

The requirement that MPI_THREAD_SINGLE implies "only one thread will
execute" is important, because it allows an MPI implementation to use
non-reentrant system and library calls, such as malloc, that cannot be
used if there any potential for other threads to call these functions.

This interpretation is quite clear if one considers the contraposition
of the following text, found on page 487 of MPI-3, lines 14-17:

"Advice to implementors. If provided is not MPI_THREAD_SINGLE then the
MPI library should not invoke C or Fortran library calls that are not
thread safe, e.g., in an environment where malloc is not thread safe,
then malloc should not be used by the MPI library."

A natural consequence of this is that the following cannot be valid.

"An MPI library that is not thread compliant must always return
provided=MPI_THREAD_SINGLE, even if MPI_INIT_THREAD is called on a
multithreaded process. The library should also return correct values
for the MPI calls that can be executed before initialization, even if
multiple threads have been spawned."

I don't have a clear idea on how to fix this, but I would tend to move
in the direction of asserting that MPI_THREAD_FUNNELED is the
"default" thread level of MPI, since it is equivalent to
MPI_THREAD_SINGLE except in regards to the existence of threads and
the use of thread-safe system calls.

Jeff

On Tue, Mar 26, 2013 at 7:26 AM, Jeff Squyres (jsquyres)
<jsquyres at cisco.com> wrote:
> Per the point that Pavan raised yesterday, I guess MPI-3 p486 says two different things:
>
> 1. Line 1 says "Only one thread will execute".  There are no qualifications made on what this thread is (application, implementation, ...whatever).  It says one thread.  Period.  This is before the term "thread compliant implementation" is defined, but this statement assumedly applies only to thread compliant implementations.
>
> 2. Lines 28-31 is specifically talking about a non-thread-complaint implementation; it says that it must return THREAD_SINGLE and provide correct answers for functions like MPI_INITIALIZED even from multiple threads (assumedly even simultaneously) before MPI has been initialized.
>
> This is an interesting datapoint in the current discussion -- it appears to go part way (but not enough) to fix the issues raised by Hammond.  Perhaps lines 28-31 were a good example of a spot fix that further muddy the waters in a holistic sense (i.e., they provide a precedence for Hammon's original "make INITIALIZED/THREAD_QUERY/etc. always thread safe" proposal, but still doesn't address the larger issue).
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
> _______________________________________________
> Mpi3-hybridpm mailing list
> Mpi3-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm



-- 
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond