[Mpi-forum] Missing MPI primitives - Probe+Wait

[N.M. Maclaren]

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.