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
