Ah, thanks! I think what Jeff proposed would retain this behavior - two switches, either of which enable thread support. Only question really was to rename the --enable-mpi-threads so it more accurately reflects what it does - namely, to enable-thread-support internal to the OMPI code base.
Problem with the current name is that it implies that it enables thread support for MPI applications - as described by the config help as well: --enable-mpi-threads Enable threads for MPI applications (default: disabled) and tended to be turned on for that purpose....and not turned on when someone used internal threads! Unfortunately, as a result, many of the internal thread lock/unlocks have never actually been tested...and don't work. :-/ On Jan 28, 2010, at 8:23 PM, Barrett, Brian W wrote: > Ralph - > > No. OPAL_HAVE_THREADS is set to 1 whenever there are either POSIX or Solaris > threads, regardless of the setting of --enable-progress-threads or > --enable-mpi-threads. OPAL_HAVE_THREAD_SUPPORT, however, is set to 1 > whenever --enable-progress-threads *OR* --enable-mpi-threads is set. So, > basically, I'm saying all the OPAL_THREAD_* macros switch behavior whenever > --enable-progress-threads or --enable-mpi-threads are set. > > Brian > > On Jan 28, 2010, at 9:55 PM, Ralph Castain wrote: > >> Yo Brian >> >> Are you saying that --enable-progress-threads automatically sets >> OPAL_HAVE_THREADS? Because otherwise the OPAL_THREAD_[UN]LOCK macros define >> to no-op, which is what is currently causing the problem. >> >>> From what I saw, the only way to get the macros to define as they should >>> was to set --enable-mpi-threads, which is what caused the confusion. >> >> I don't have a strong opinion on the name, other than that it should be >> clear as to what it does (which is not the current case). Just want to make >> sure I understand your response. >> >> >> On Jan 28, 2010, at 7: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 >> >> >> _______________________________________________ >> 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
