[Mpi-22] Dynamic thread levels

[Richard Treumann]

Pavan,

Can you explain what improvements you expect if MPI added this?

If an MPI implementation that is capable of supporting MPI_THREAD_MULTIPLE
is running in MPI_THREAD_SINGLE mode, that probably means all protection
against multiple threads is being bypassed at rather modest latency
savings. The savings probably come from branching over lock operations.
Ongoing checking for concurrent threads making MPI calls is expensive
enough so doing it would eat up much of the savings from branching over
lock operations.  Basically, the MPI_THREAD_MULTIPLE capable MPI running in
MPI_THREAD_SINGLE mode is probably defenseless  against multi thread
applications.

What this means for MPI_Set_thread_level(int required, int * provided);

is that the application would need to take full responsibility for making
sure there is only one thread making MPI calls at the moment a mode switch
is requested. If the application gets it wrong there is probably nothing
(affordable) the MPI implementation can do to detect the danger.
Applications that turned thread safety on and off but were misusing the
call would never get an error message and might run without problems 99
times out of 100.  1% of the runs would have mysterious failures and the
failures might each look quite different.

It is certainly possible for an MPI implementation that only supports
MPI_THREAD_SINGLE to do some things faster by using simpler global data
structures but such an MPI implementation could not honor a runtime request
to convert to MPI_THREAD_MULTIPLE. It may even be possible for an MPI
implementation at INIT time to chose simple vs. thread safe data structures
but again, a switch once everything is up and running is probably not
practical.

This does not seem to me to offer enough payoff to justify the dangers.

         Dick

Dick Treumann  -  MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363

mpi-22-bounces_at_[hidden] wrote on 09/04/2008 04:30:23 AM:

> [image removed]
>
> [Mpi-22] Dynamic thread levels
>
> Pavan Balaji
>
> to:
>
> mpi-22
>
> 09/04/2008 04:39 AM
>
> Sent by:
>
> mpi-22-bounces_at_[hidden]
>
> Please respond to "MPI 2.2"
>
> Hi all,
>
> I would like to propose an addition of a function call to dynamically
> modify the thread level required by the application, instead of at
> MPI_Init_thread() time. I'm sending this over email for comments
> (attached with this email); I'll upload it on the wiki this evening.
>
>   -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> Dynamic Thread Levels
>
> Author: Pavan Balaji, Argonne National Laboratory
>
> Background:
>
> MPI 2.1 standard allows users to set thread level only at
> MPI_Init_thread time. This means that for applications that
> dynamically create threads (e.g., hybrid MPI + OpenMP applications),
> even non-threaded portions of the application have to rely on the
> maximum thread level used in the application (e.g., MULTIPLE).
>
>
> Proposal:
>
> Add an additional function call to dynamically set thread-level during
> the application.
>
>   int MPI_Set_thread_level(int required, int * provided);
>
>
> Rational:
>
> The requirement to specify the thread-level at MPI_Init_thread time is
> too restrictive for applications that perform a small amount of
> communication requiring a high-level of thread support. For
> correctness, the standard requires all of the code to follow the same
> thread-level, and provides the applications with no way to give the
> MPI library more information about their behavior.
>
>
> Impact on MPI implementations:
>
> Most MPI implementations already provide runtime support for
> thread-level, i.e., locks are compiled in, but whether they are
> invoked or not is decided at runtime. For implementations that choose
> not to respect this option, MPI_Set_thread_level() can just set the
> provided level to the current level, by ignoring the required level
> specified by the user.
>
>
> Impact on MPI applications:
>
> Existing MPI applications do not need to be modified at all. But newer
> applications can benefit from this additional functionality.
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22





* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080904/fc3f7b08/attachment.html>