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

Missing MPI primitives - Probe+Wait
by N.M. Maclaren 19 Apr '10

19 Apr '10

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.

1 0

Re: [Mpi-forum] Hotel for the upcoming meeting
by Graham, Richard L. 14 Apr '10

14 Apr '10

It seems like only 5 folks have actually registered to use the hotel, but the hotel was gracious to extend the deadline to Friday, 4/23. We are committed to 16 rooms on Monday and Tuesday, which we usually make with out a problem. If we stay low like this, I expect this will be the last time we reserve a block of rooms, as I don't want to waste money on unused rooms. Rich On 4/13/10 8:45 PM, "Rich Graham" <rlgraham(a)ornl.gov> wrote: If any of you still want a hotel room in the meeting block, and have trouble getting one, please let us know. I don't think we have met our room commitment, so would like to avoid a penalty, if at all possible. Thanks, Rich _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Hotel for the upcoming meeting
by Graham, Richard L. 13 Apr '10

13 Apr '10

If any of you still want a hotel room in the meeting block, and have trouble getting one, please let us know. I don't think we have met our room commitment, so would like to avoid a penalty, if at all possible. Thanks, Rich

1 0

Execution MPI program on one node
by Zain elabedin hammade 11 Apr '10

11 Apr '10

Hello ... Execution MPI program on one node is a parallel execution , isn't it? How is it done? regarded. _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969

1 0

Fwd: [all-osl-users] Upgrading trac
by Jeff Squyres 09 Apr '10

09 Apr '10

FYI -- short Trac/SVN outage next Monday. Begin forwarded message: > From: "Kim, DongInn" > Date: April 9, 2010 2:19:33 PM EDT > Subject: [all-osl-users] Upgrading trac > > The OSL will upgrade trac from 0.11.5 to 0.11.7 on sourcehaven next Monday(4/12/2010)? > > Date: Monday, April 12, 2010. > Time: > - 5:00am-5:30am Pacific US time > - 6:00am-6:30am Mountain US time > - 7:00am-7:30am Central US time > - 8:00am-8:30am Eastern US time > - 12:00pm-12:30pm GMT > > > We will have a short outage(half hour) of apache server and the following services would not be available during the upgrade. > > - trac > - subversion > - svn check-in hook to trac > > Please let me know if you have any questions or issues of the this upgrade. > > -- > - DongInn > > -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

May meeting in Chicago
by Graham, Richard L. 08 Apr '10

08 Apr '10

Just a reminder that the block of rooms for this meeting is available until this coming Monday, 4/12/2010. To register for the meeting, please go to https://www.ornl.gov/ccsd_registrations/nccs_mpi_forums/ Thanks, Rich

1 0

Re: [Mpi-forum] MPI_Abort - meaning
by N.M. Maclaren 06 Apr '10

06 Apr '10

On Apr 6 2010, Richard Treumann wrote: > >This again brings me back to thinking perhaps the MPI standard cannot offer >any decent semantic for a single task making a decision to terminate with >success and the people who want this for their applications cannot have it. I believe that the best that could be done is to specify that, if precisely one process calls MPI_Quit and no process calls MPI_Abort, the process that called MPI_Quit leaves through normal language termination. I.e. local files would be closed and similar cleanup performed, but nothing else would be specified. Even that would rely on the process not attempting to close down MPI cleanly and have the close activity collapse under its feet. Cleanup after failure is HARD. But you know that. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] MPI_Abort - meaning
by N.M. Maclaren 06 Apr '10

06 Apr '10

On Apr 6 2010, Jeff Squyres wrote: > >> I agree with Richard's reservations, incidentally. About the best that >> can be done is to specify an MPI_Quit that stops the calling process >> cleanly (in the language sense) and has the effect of MPI_Abort on the >> others. But, as I said, even that is tricky to implement on some systems >> and may not be reliable. > > You mentioned this in an earlier post -- can you explain some issues? For > example, you mention it might be difficult with systems that use sysv > shared memory. Why? All it can do is detach the segment - if another process that has it attached goes belly-up, the segment remains lurking. The point is that, in ANY design, shared resources can be freed only when the last client using them has stopped doing so, and (in general) that requires all clients to clean up properly. > I ask with the *assumption* that the MPI implementation can/will have > some kind of helper run-time system around that can do whatever cleanup > is required (MPI-2 dynamics more-or-less require this anyway). I know :-( It's one of the many reasons that I think they are a ghastly idea. > Keep in > mind that I'm not saying that the run-time system has to be part of the > MPI implementation -- it may simply be provided on the system. For > example: if sysv memory segments are left lying around because MPI > processes are killed by the run-time system, a high-quality run-time > system should be able to clean up the shared memory as well (or at least > provide hooks such that MPI processes can tell the run-time system about > resources that would need to be cleaned up in the event of untimely MPI > process deaths, such as sysv shared memory segments). > >Is that a bad assumption? Yes. That can be done on zOS (previously MVS) and, I believe, VMS. Just. But you don't have an earthly under almost any Unix-derived system (including, I believe, all of Microsoft's). The point is that there is no way for an unprivileged application to set up a 'super-process' that can guarantee to get control, and have the power to clean up. Consider when running under a job scheduler, and it decides to kill the MPI job. You can't control which processes it kills and in which order. In particular, the clean-up process may not run until after the extra time allowed for cleaning up has passed. So you need to make the job scheduler the clean-up process or integrate it with the MPI. But it gets worse. Consider a MPI process that is waiting on a TCP/IP access. In general, no unprivileged code can kill that process and put it into termination to release the resources. So you now need to integrate the operating system with the job scheduler with the MPI. And many Unices have quite a lot of resources like that. When you have NFS access problems (not exactly rare), even that may not work .... Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] MPI_Abort - meaning
by Jeff Squyres 06 Apr '10

06 Apr '10

On Apr 6, 2010, at 4:51 PM, Richard Treumann wrote: > This again brings me back to thinking perhaps the MPI standard cannot offer any decent semantic for a single task making a decision to terminate with success and the people who want this for their applications cannot have it. It's almost the same semantic as: if (i_have_reached_a_good_state) { printf("Hey user -- we're good. Hit ctrl-c, will ya?\n"); while (1) sleep(100000); } Right? I know that ctrl-c processing (or equivalent) is not mandated -- but it's supported by all MPI implementations. I would assume that your initial assertions are useful: basically, no guarantees are given about the state of anything. If you're calling MPI_QUIT, you're doing so because you don't want to implement a (perhaps complex) control protocol that can shut down all MPI processes in an orderly fashion. You want a more-or-less immediate shutdown of all MPI processes with indication of a "successful" shutdown. I'm sure there's some corner cases to figure out, though -- here's a few off the top of my head: - what happens if MPI_QUIT and MPI_ABORT are invoked simultaneously in multiple MPI processes? What about in the same process? - what happens if an error occurs in MPI_QUIT processing? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] MPI_Abort - meaning
by Richard Treumann 06 Apr '10

06 Apr '10

Jeff asked why it might be problematic to make MPI_Abort or MPI_Quit into a reliable (as opposed to "best effort") job termination. He mentioned the assumption that any parallel job must be under control of some supervisor that can clean up. This assumption may actually identify one root of a problem. If the supervisor has lost its full connectivity but the tasks of a job are still able to communicate then MPI_Finalize might still be able to promise clean termination. A call to MPI_Abort or MPI_Quit may be unable to do anything about tasks that are outside the reach of its own subset of the broken supervisor. Also, any idea of clean termination by either MPI_Abort or MPI_Quit becomes very messy if you consider MPI-IO (or any cooperative file writing). If some tasks are working together on an MPI_File_write_xxxx and some task throws the ABORT bomb (or QUIT bomb), it is probably not feasible to make any promise about the state of the file. This again brings me back to thinking perhaps the MPI standard cannot offer any decent semantic for a single task making a decision to terminate with success and the people who want this for their applications cannot have it. 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