On the WG call today, we determined that #360 should be withdrawn because there is a larger threading problem with the text describing MPI_T_INIT_THREAD. (we can discuss all of this further next week in the Tools WG time slot) Specifically, MPI-3 p564:7-10 says (describing MPI_T_INIT_THREAD): The argument *required* is used to specify the desired level of thread support. The possible values and their semantics are identical to the ones that can be used with MPI_INIT_THREAD listed in Section 12.4. The problem is this: if we allow MPI_T_INIT_THREAD to have thread levels with *identical semantics* to the ones for MPI_INIT_THREAD, then that means MPI_T needs to have a concept of a "main thread". And if that's the case, what's the relation between the MPI_T main thread and the MPI main thread? For example, what does it mean if MPI_T has a different main thread than MPI's main thread, and one or both of them return provided==MPI_THREAD_SINGLE? None of this is specified. We need to decide what we want to do with the threading model before we can decide how we want to resolve #360 (i.e., the wording of #360 is dependent upon the resolution of this issue). Here's the bare-bones/zen of a possible solution: - The MPI_T interface is effectively divorced from the MPI interface. For example, the thread levels provided by MPI_T and MPI may be different. If we preserve the concept of a "main thread" for MPI_T, it is unrelated to the MPI main thread. - This may or may not need to be stated in the doc, but: an MPI_T's quality and/or functionality may be determined by whether it is the same main thread as MPI. For example, if MPI_T's main thread is different than MPI's main thread, it may only provide read-only access to control variables -- but may be able to provide read/write access if MPI_T's main thread === MPI's main thread. -- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/