On Apr 20 2010, Dave Goodell wrote:

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).

And more :-( We are all agreed, there. It was said merely in the context of "this may look like a solution, but isn't".

...

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.

Most of that's true, but Solaris isn't a counter-example to my point. That was one of the systems where I have seen trouble. My comment was that doing that is not sufficient - yes, it's necessary, but things are MUCH fouler than the paragraph implies. In particular, MPI has no control over when its underlying facilities (INCLUDING when it's in a kernel thread) choose to handle signals that are intended for and handled by another thread. After all, how signals addressed to a process get bound to threads is effectively undefined.

Do you have a suggestion for how this paragraph could be improved?

I would change "avoid" to "minimise" and "catch" to "handle". That would be enough of an improvement to avoid conflict with what happens. The last sentence is a bit like "High quality programs will never fail no matter what their input, and will always return a correct answer or correctly diagnose the fault in their input." Well, maybe, .... However, I don't think that it needs changing. Regards, Nick Maclaren.