April 2010 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] MPI 2.2 C++ bindings
by Dave Goodell 23 Apr '10

23 Apr '10

On Apr 23, 2010, at 3:54 PM, Richard Treumann wrote: > Has anyone implemented the C++ bindings for the new MPI 2.2 APIs? I > am not a C++ expert but it seems to me there are several errors. > Even if they are deprecated, they are required for now. > Can you be a little more specific about where the problems are? The MPICH2 C++ bindings are mostly auto-generated, so we have at least partially implemented them already (e.g. I see MPI::Reduce_scatter_block in mpicxx.h). But I don't think that we wrote any C++ tests for the few new APIs that were introduced and I don't know if any of it works. -Dave

1 0

Re: [Mpi-forum] MPI 2.2 C++ bindings
by Jeff Squyres 23 Apr '10

23 Apr '10

Can you cite some examples of the errors? On Apr 23, 2010, at 4:54 PM, Richard Treumann wrote: > Has anyone implemented the C++ bindings for the new MPI 2.2 APIs? I am not a C++ expert but it seems to me there are several errors. Even if they are deprecated, they are required for now. > > Dick > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

MPI 2.2 C++ bindings
by Richard Treumann 23 Apr '10

23 Apr '10

Has anyone implemented the C++ bindings for the new MPI 2.2 APIs? I am not a C++ expert but it seems to me there are several errors. Even if they are deprecated, they are required for now. Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363

1 0

May 3-5 meeting
by Graham, Richard L. 20 Apr '10

20 Apr '10

I have updated the agenda to reflect requests by some working groups for more time. IMPORTANT: If the Backward compatibility working group is able to come up with a first cut at a formal proposal for the MPI_Count issue by the end of this week - Friday 4/23/2010, we will have a formal reading of this proposal at the upcoming meeting. If not, the working group will report back to the forum on what should be a formal proposal at the June meeting. Reminder: This Friday is also the cutoff date for a room in the meeting room block. Rich

1 0

Re: [Mpi-forum] Missing MPI primitives - Probe+Wait
by N.M. Maclaren 20 Apr '10

20 Apr '10

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

1 0

Re: [Mpi-forum] Missing MPI primitives - Probe+Wait
by Dave Goodell 20 Apr '10

20 Apr '10

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

1 0

Re: [Mpi-forum] Missing MPI primitives - Probe+Wait
by N.M. Maclaren 20 Apr '10

20 Apr '10

On Apr 20 2010, William Gropp wrote: >I just wanted to respond to this. In fact, the Forum was well aware >of how incomplete the POSIX thread standard was and was careful to not >mandate them (!) - we did receive suggestions from people who thought >MPI codes would be *more* portable if we said MPI must support pthreads. I certainly didn't mean to imply that it wasn't - the specification makes it very clear that it was! All an implementation is required is to tell the programmer what it supports, which suits me - the answer might even be correct! Similarly, the issues of progress, scheduling and memory consistency were clearly understood, as the remarks on MPI-2 one-sided communication make clear. It also makes it clear that hairy things like IEEE exception flags and signals are "here be dragons". One of my main reasons to stick to MPI-1 is that it is as near to bulletproof as one can hope to get nowadays. I have come across very, very few MPI implementations where facilities deliver the syntax but not the semantics, and then only in ways that were simple bugs, and not design restrictions. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] Missing MPI primitives - Probe+Wait
by William Gropp 20 Apr '10

20 Apr '10

I just wanted to respond to this. In fact, the Forum was well aware of how incomplete the POSIX thread standard was and was careful to not mandate them (!) - we did receive suggestions from people who thought MPI codes would be *more* portable if we said MPI must support pthreads. Bill 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. William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-forum] Missing MPI primitives - Probe+Wait
by N.M. Maclaren 20 Apr '10

20 Apr '10

On Apr 19 2010, Solt, David George wrote: >Can you do an MPI_Iprobe + MPI_Waitall(iprobe request + other requests)? > > Regarding "of the form that will yield to other threads and processes, > not a spin loop" is currently considered and implementation artifact and > it is up to a particular MPI implementation if they want to spin or block > or yield or expose how waiting is handled to the user. Yes, agreed. I wasn't writing a specification, but expressing the intent. One of the Great Myths of parallel programming is that timing and progress issues are semantically neutral - they aren't, as MPI-2 notes in the section on one-sided communication. MPI-1 is about as much as you can do while remaining semantically neutral, and there are some gotchas even there. The point about such a facility is that it would ALLOW an implementation to deliver what it needed, so at least the program could be syntactically portable. At present, even that isn't possible. > The 2nd request could be handled in a number of ways using current API's > primitives, but would all require MPI_THREAD_MULTIPLE to be set. I > believe you will need to argue a strong case for why multiple threads > should be able to simultaneously call any existing or desired MPI AI's > without MPI_THREAD_MULTIPLE set. Your first sentence is precisely why I posted this! The reason is implementability. I believe that I could implement what I asked for, fairly reliably, on every major system I know about. I know of none on which I could implement MPI_THREAD_MULTIPLE without relying on undefined behaviour, and I very much doubt that it will ever be possible to write a non-trivial, portable, reliable MPI_THREAD_MULTIPLE program. 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). Incidentally, the second paragraph of 2.9.2 is false. If only it were that simple :-( Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] Missing MPI primitives - Probe+Wait
by Solt, David George 19 Apr '10

19 Apr '10

Can you do an MPI_Iprobe + MPI_Waitall(iprobe request + other requests)? Regarding "of the form that will yield to other threads and processes, not a spin loop" is currently considered and implementation artifact and it is up to a particular MPI implementation if they want to spin or block or yield or expose how waiting is handled to the user. The 2nd request could be handled in a number of ways using current API's primitives, but would all require MPI_THREAD_MULTIPLE to be set. I believe you will need to argue a strong case for why multiple threads should be able to simultaneously call any existing or desired MPI AI's without MPI_THREAD_MULTIPLE set. Thanks, Dave Solt -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of N.M. Maclaren Sent: Monday, April 19, 2010 3:35 PM To: Main MPI Forum mailing list Subject: [Mpi-forum] Missing MPI primitives - Probe+Wait I have been drafting a design for Fortran coarrays based on MPI, and have hit a couple of rather critical missing primitives. One is that I need to do a blocking wait (of the form that will yield to other threads and processes, not a spin loop) that will terminate as soon as either a message comes in (i.e. like MPI_Probe) or one of the outstanding non-blocking messages completes (i.e. like MPI_Waitall). Another is the ability to interrupt one of those primitives (or, I suppose, MPI_Probe or one of the MPI_Waits) from another thread in the same process in the case that MPI_THREAD_MULTIPLE is NOT set. No message needed - just a way of breaking out. The first could easily be added by a pseudo-request that was satisfied by the existence of an incoming message - obviously, the status would be full of the usual 'unset' values - or by adding a separate function. I doubt that it would be any trickier to implement than MPI_Waitany. The second is easy to specify. It would need a three-state return value: success, not in a wait, or failure. Allowing the last would make it reliably implementable, though not ideal for my purposes :-( I can see how to implement it in most cases, so that opt-out should rarely be used. But there are circumstances when it would be needed. Any comments? Including that I have been an idiot and missed something obvious :-) Regards, Nick Maclaren. _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0