Actually, the problem was not that we have too many options but that we are not taking advantage of the features for doing tests - in fact, the "multiple" option would have (and should have!) helped identify the problems without requiring (admittedly useful) enhancements to the test programs. In fact, it makes more sense to restore the "multiple" option to make it easier to apply test suites (including ones that only call MPI_Init) in order to perform more thorough testing of the thread code. There are good arguments for reducing some of the options, but this must be done recognizing that MPICH2 must first and foremost be a research vehicle for MPI implementations - that will require supporting more options than are appropriate for a product that implements MPI for some platforms. Having said that, some of the current flexibility in supporting thread levels may not be needed and can be reduced, though I don't agree with the proposed mapping (and note that runtime can't be the general default, as the default choice depends on the capabilities of the device and channel). Reducing the options should be done carefully and openly, and after a discussion of all of the issues. Bill On Sep 29, 2010, at 11:24 AM, Rajeev Thakur wrote:

Yes, and it should probably be fixed. It is getting too hard to maintain multiple options of thread support, i.e., such bugs creep in. We were talking about supporting just two, single and runtime, with funneled, serialized, and multiple being mapped to runtime.

Rajeev

On Sep 29, 2010, at 11:17 AM, William Gropp wrote:

...

But shouldn't the programs continue to work if multiple was selected? Doesn't this mean that there is a bug in the thread implementation (e.g., run that test with MPICH_THREADLEVEL_DEFAULT=multiple)? In fact, I was able to confirm that this is the case. I've enhanced the MTest_Init to accept MTEST_THREADLEVEL_DEFAULT (similar to how MPICH_THREADLEVEL_DEFAULT is accepted by MPI_Init) and caused these tests to run with the (runtime) thread level of MPI_THREAD_MULTIPLE. The attribute tests then failed. Turning off the multiple option just masked bugs in the thread support within the attribute (and other) routines.

Bill

On Sep 28, 2010, at 5:17 PM, mpich2 wrote:

...

#1100: --enable-threads=multiple results in deadlocks ---------------------- +----------------------------------------------------- Reporter: buntinas | Owner: goodell Type: bug | Status: closed Priority: major | Milestone: mpich2-1.3 Component: mpich2 | Resolution: fixed Keywords: | ---------------------- +----------------------------------------------------- Changes (by thakur):

* status: new => closed * resolution: => fixed

Comment:

Set multiple = runtime in r7261. We can revert it back later if multiple is really needed.

-- Ticket URL: <http://trac.mcs.anl.gov/projects/mpich2/ticket/1100#comment:3

...

mpich2 <http://www.mcs.anl.gov/research/projects/mpich2> MPICH2 is a high-performance and widely portable implementation of MPI

William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

_______________________________________________ mpich2-maint mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/mpich2-maint

William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign