I honestly wasn't casting aspersions - just sounds like a very strange operational mode. Never heard of something like that before.
The problem is that we continue to have issues with clean termination and "hangs", largely because the program counter gets "hung" as we try to work with an event-driven system constrained to a single thread. We also have performance problems because we cannot progress communications asynchronously. So the movement is to threading mpirun and the orte daemons to solve the problems. Maintaining both threaded and unthreaded operations inside a single code becomes a study in spaghetti, and so it may prove intractable. In that case, I'll "freeze" an unthreaded version at the current level, and we'll focus further development on the threaded version. If we go that route (and that isn't a given yet), then I'll rig the build system so configuring without threads generates the unthreaded version, with the correct accompanying man page. HTH Ralph On Oct 12, 2010, at 9:15 AM, Kenneth Lloyd wrote: > Ralph, > > There is really no need to do anything different to accommodate us "oddball" > cases. Continue to "do what you do". > > Ken > > -----Original Message----- > From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On > Behalf Of Ralph Castain > Sent: Tuesday, October 12, 2010 9:01 AM > To: Open MPI Developers > Subject: Re: [OMPI devel] Threading > > Hmmm...I don't understand what you just said, but it definitely sounds > -ugly-! :-) > > I'll take your word for it - we may have to provide a lower performance > version for such oddball purposes, and offer a higher capability version for > everyone else. I'll see if I can keep a single version, though, assuming the > code doesn't get too convoluted so as to become unmaintainable. > > Otherwise, I'll branch it and "freeze" a non-threaded version for the > unusual case. > > Thanks! > > On Oct 12, 2010, at 8:51 AM, Kenneth Lloyd wrote: > >> In certain hybrid, heterogeneous HPC configurations, mpirun often cannot > or >> should not be threaded through the OS under which OpenMPI runs. The > primary >> OS and MPI can configure management nodes and topologies (even other MPI >> layers) that subsequently spawn various OSes and other lightweight > kernels. >> These share memory spaces and indirectly access the program stacks in >> various devices. >> >> In short, yes, there are environments where this would cause a problem. >> >> ================== >> Kenneth A. Lloyd >> Watt Systems Technologies Inc. >> >> >> -----Original Message----- >> From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On >> Behalf Of Barrett, Brian W >> Sent: Tuesday, October 12, 2010 8:24 AM >> To: Open MPI Developers >> Subject: Re: [OMPI devel] Threading >> >> On Oct 11, 2010, at 11:41 PM, Ralph Castain wrote: >> >>> Does anyone know of a reason why mpirun can -not- be threaded, assuming >> that all threads block and do not continuously chew cpu? Is there an >> environment where this would cause a problem? >> >> We don't have any machines at Sandia where I could see this being a > problem. >> >> Brian >> >> -- >> Brian W. Barrett >> Dept. 1423: Scalable System Software >> Sandia National Laboratories >> >> >> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
