On Apr 20, 2010, at 3:27 AM, N.M. Maclaren wrote:

I don't know how well you (or others) know POSIX threads and how they are implemented, or other threading interfaces, but the assumption that you can write portable code is completely false. For example, POSIX contains no specification of how non-memory actions (including almost everything that happens inside a library call) can be synchronised. FAR worse are the number of facilities that are neither thread-neutral nor thread-specific (signals is the extreme case, but even network I/O is often like that, and MPI rather relies on it).

As Bill pointed out, this isn't something that MPI can solve. These are shortcomings of pthreads (it provides only heavyweight synchronization with lots of implementation wiggle room) and the C language (it lacks a memory model and any notion of multiple threads).

Incidentally, the second paragraph of 2.9.2 is false. If only it were that simple :-(

Quoted for the list's benefit: -------8<------- In multithreaded environments, users can avoid conflicts between signals and the MPI library by catching signals only on threads that do not execute MPI calls. High quality single-threaded implementations will be signal safe: an MPI call suspended by a signal will resume and complete normally after the signal is handled. -------8<------- Perhaps it should be an "Advice to users", but I don't think that the paragraph is universally false. I think the multithreading bit is/was accurate for some platforms (Solaris threads maybe?), as long as you jump through some hoops and sigwait. It will also depend on the particular signals involved. Do you have a suggestion for how this paragraph could be improved? -Dave