On Mar 10 2011, Eugene Loh wrote:
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).
And so it goes ....
Regards,
Nick Maclaren.
