On Feb 9, 2010, at 1:44 AM, Sylvain Jeaugey wrote: > While we're at it, why not call the option giving MPI_THREAD_MULTIPLE support > --enable-thread-multiple ?
Makes sense to me. I agree with Brian that we need three options here. > > About ORTE and OPAL, if you have --enable-thread-multiple=yes, it may force > the usage of --enable-thread-safety to configure OPAL and/or ORTE. It definitely will, but I don't see that as an issue. > > I know there are other projects using ORTE and OPAL, but the vast majority of > users are still using OMPI and were already confused by --enable-mpi-threads. > Switching to --enable-multi-threads or --enable-thread-safety will surely > confuse them one more time. > Just to clarify: this actually isn't about other projects. Jeff misspoke, IMO. The problem is in OMPI as it may be necessary/advantageous for ORTE to have threads for proper mpirun and orted operation even though application processes don't use them. Ralph > Sylvain > > On Mon, 8 Feb 2010, Barrett, Brian W wrote: > >> Well, does --disable-multi-threads disable progress threads? And do you >> want to disable thread support in ORTE because you don't want >> MPI_THREAD_MULTIPLE? Perhaps a third option is a rational way to go? >> >> Brain >> >> On Feb 8, 2010, at 6:54 PM, Jeff Squyres wrote: >> >>> How about >>> >>> --enable-mpi-threads ==> --enable-multi-threads >>> ENABLE_MPI_THREADS ==> ENABLE_MULTI_THREADS >>> >>> Essentially, s/mpi/multi/ig. This gives us "progress thread" support and >>> "multi thread" support. Similar, but different. >>> >>> Another possibility instead of "mpi" could be "concurrent". >>> >>> >>> >>> On Jan 28, 2010, at 9:24 PM, Barrett, Brian W wrote: >>> >>>> Jeff - >>>> >>>> I think the idea is ok, but I think the name needs some thought. There's >>>> currently two ways to have the lower layers be thread safe -- enabling MPI >>>> threads or progress threads. The two can be done independently -- you can >>>> disable MPI threads and still enable thread support by enabling progress >>>> threads. >>>> >>>> So either that behavior would need to change or we need a better name (in >>>> my opinion...). >>>> >>>> Brian >>>> >>>> On Jan 28, 2010, at 8:53 PM, Jeff Squyres wrote: >>>> >>>>> WHAT: Rename --enable-mpi-threads and ENABLE_MPI_THREADS to >>>>> --enable-thread-safety and ENABLE_THREAD_SAFETY, respectively >>>>> (--enable-mpi-threads will be maintained as a synonym to >>>>> --enable-thread-safety for backwards compat, of course). >>>>> >>>>> WHY: Other projects are starting to use ORTE and OPAL without OMPI. The >>>>> fact that thread safety in OPAL and ORTE requires a configure switch with >>>>> "mpi" in the name is very non-intuitive. >>>>> >>>>> WHERE: A bunch of places in the code; see attached patch. >>>>> >>>>> WHEN: Next Friday COB >>>>> >>>>> TIMEOUT: COB, Friday, Feb 5, 2010 >>>>> >>>>> ------------------------ >>>>> >>>>> More details: >>>>> >>>>> Cisco is starting to investigate using ORTE and OPAL in various threading >>>>> scenarios -- without the OMPI layer. The fact that you need to enable >>>>> thread safety in ORTE/OPAL with a configure switch that has the word >>>>> "mpi" in it is extremely counter-intuitive (it bit some of our engineers >>>>> very badly, and they were mighty annoyed!!). >>>>> >>>>> Since this functionality actually has nothing to do with MPI (it's >>>>> actually the other way around -- MPI_THREAD_MULTIPLE needs this >>>>> functionality), we really should rename this switch and the corresponding >>>>> AC_DEFINE -- I suggest: >>>>> >>>>> --enable|disable-thread-safety >>>>> ENABLE_THREAD_SAFETY >>>>> >>>>> Of course, we need to keep the configure switch >>>>> "--enable|disable-mpi-threads" for backwards compatibility, so that can >>>>> be a synonym to --enable-thread-safety. >>>>> >>>>> See the attached patch (the biggest change is in >>>>> opal/config/opal_config_threads.m4). If there are no objections, I'll >>>>> commit this next Friday COB. >>>>> >>>>> -- >>>>> Jeff Squyres >>>>> jsquy...@cisco.com >>>>> <opal-thread-safety.diff>_______________________________________________ >>>>> devel mailing list >>>>> de...@open-mpi.org >>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >> >> -- >> 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
