> Any comments on this? We wanted to clean up MPI_THREAD_MULTIPLE
>support in the trunk and port these changes back to 1.5.x, but it's
>unclear to me what our expectations should be about any
>MPI_THREAD_MULTIPLE test succeeding. How do we assess (test) our
>changes? Or, should we just hardwire thread support to be off, as we
>have done with progress threads?

Please, Please, PLEASE do the latter - at least for MPI_THREAD_SERIALIZED
and MPI_THREAD_MULTIPLE!

There is NO chance that it will ever be reliable and portable while POSIX
threads are in the state they are in. Even reaching MPI_THREAD_FUNNELED
requires FAR more complexity than most experienced programmers expect.
The Microsoft specifications I have found are no better. For example,
here are a few issues that I have seen:

Most functions are defined to be 'thread-safe' - which is useless without
a specification of what that means. To take a simple example, consider
scanf versus ungetc versus lseek ....

There are no facilities for synchronising non-memory actions, from I/O
to signals. POSIX requests read and write to be atomic, but does not
specify it, and it gets extremely hairy to know what that means with a
TCP transfer actually in progress.

Signals are particularly hairy, because I have seen one thread handle
and clear a signal, synchronise with another, which then was told that
the same signal was waiting by sigpending (only to have it disappear
when it was masked back on).