<html><body>
<p>Pavan, <br>
<br>
Can you explain what improvements you expect if MPI added this?<br>
<br>
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.<br>
<br>
What this means for <tt>MPI_Set_thread_level(int required, int * provided); </tt><br>
<br>
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. <br>
<br>
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. <br>
<br>
This does not seem to me to offer enough payoff to justify the dangers.<br>
<br>
Dick <br>
<br>
Dick Treumann - MPI Team <br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-22-bounces@lists.mpi-forum.org wrote on 09/04/2008 04:30:23 AM:<br>
<br>
> [image removed] </tt><br>
<tt>> <br>
> [Mpi-22] Dynamic thread levels</tt><br>
<tt>> <br>
> Pavan Balaji </tt><br>
<tt>> <br>
> to:</tt><br>
<tt>> <br>
> mpi-22</tt><br>
<tt>> <br>
> 09/04/2008 04:39 AM</tt><br>
<tt>> <br>
> Sent by:</tt><br>
<tt>> <br>
> mpi-22-bounces@lists.mpi-forum.org</tt><br>
<tt>> <br>
> Please respond to "MPI 2.2"</tt><br>
<tt>> <br>
> Hi all,<br>
> <br>
> I would like to propose an addition of a function call to dynamically <br>
> modify the thread level required by the application, instead of at <br>
> MPI_Init_thread() time. I'm sending this over email for comments <br>
> (attached with this email); I'll upload it on the wiki this evening.<br>
> <br>
> -- Pavan<br>
> <br>
> -- <br>
> Pavan Balaji<br>
> <a href="http://www.mcs.anl.gov/~balaji">http://www.mcs.anl.gov/~balaji</a><br>
> Dynamic Thread Levels<br>
> <br>
> Author: Pavan Balaji, Argonne National Laboratory<br>
> <br>
> Background:<br>
> <br>
> MPI 2.1 standard allows users to set thread level only at<br>
> MPI_Init_thread time. This means that for applications that<br>
> dynamically create threads (e.g., hybrid MPI + OpenMP applications),<br>
> even non-threaded portions of the application have to rely on the<br>
> maximum thread level used in the application (e.g., MULTIPLE).<br>
> <br>
> <br>
> Proposal:<br>
> <br>
> Add an additional function call to dynamically set thread-level during<br>
> the application.<br>
> <br>
> int MPI_Set_thread_level(int required, int * provided);<br>
> <br>
> <br>
> Rational:<br>
> <br>
> The requirement to specify the thread-level at MPI_Init_thread time is<br>
> too restrictive for applications that perform a small amount of<br>
> communication requiring a high-level of thread support. For<br>
> correctness, the standard requires all of the code to follow the same<br>
> thread-level, and provides the applications with no way to give the<br>
> MPI library more information about their behavior.<br>
> <br>
> <br>
> Impact on MPI implementations:<br>
> <br>
> Most MPI implementations already provide runtime support for<br>
> thread-level, i.e., locks are compiled in, but whether they are<br>
> invoked or not is decided at runtime. For implementations that choose<br>
> not to respect this option, MPI_Set_thread_level() can just set the<br>
> provided level to the current level, by ignoring the required level<br>
> specified by the user.<br>
> <br>
> <br>
> Impact on MPI applications:<br>
> <br>
> Existing MPI applications do not need to be modified at all. But newer<br>
> applications can benefit from this additional functionality.<br>
> _______________________________________________<br>
> mpi-22 mailing list<br>
> mpi-22@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</a><br>
</tt></body></html>