[Mpi-forum] Missing MPI primitives - Probe+Wait
nmm1 at cam.ac.uk
Tue Apr 20 09:21:06 CDT 2010
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:
>In multithreaded environments, users can avoid conﬂicts 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.
>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.
More information about the mpi-forum