I'm not going to commit this today - I think it would be a little quick :-)
However, I do have it all building on a Mercurial branch with the new options. It would be REALLY GOOD if people interested in thread support were to check this out prior to me bringing it to the trunk. The branch can be cloned with: hg clone https://r...@bitbucket.org/rhc/ompi-threads/ Please let me know if you test it and what you find. Thanks Ralph On Mar 5, 2010, at 4:18 AM, Terry Dontje wrote: > A couple comments: > 1. I really assume the timeout is March 5th not February. > 2. As to keeping the deprecated variables I think you really need to ditch > the --enable-mpi-threads because if you synonym it with > --enable-mpi-thread-multiple you are not mimicing what it did before but > redefining it IMHO. (I am ok with the ditching personally). > > --td > > Jeff Squyres wrote: >> WHAT: Rename the --enable-*-threads configure switches and ENABLE*THREAD* >> macros. >> (see previous RFC: >> http://www.open-mpi.org/community/lists/devel/2010/01/7366.php) >> >> WHY: The fact that thread safety in OPAL and ORTE requires a configure >> switch with "mpi" in the name is very non-intuitive. Additionally, >> MPI_THREAD_MULTIPLE support is not necessarily the same thing as OPAL thread >> support (MTM needs OPAL thread support, but not the other way around), and >> we are seeing a growing advantage/need for ORTE to utilize threads in mpirun >> and orted irrespective of the MPI layer's threading abilities. >> >> WHERE: Mostly opal/config/opal_config_threads.m4, something new in >> ompi/config/*.m4, and wherever the current ENABLE*THREAD* macros are >> currently used in the current code base. >> >> 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. 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!!). In addition, we ran into problems where it was >> advantageous to have threads in ORTE, but we couldn't do it without forcing >> thread support into the MPI layer because the switch is universal. >> >> 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 divorce MPI threading functionality from whether threading >> machinery is enabled in OPAL or not. >> These names were proposed at the end of the previous RFC and no one >> objected, so I'm sending this around as a new RFC to ensure we're all on the >> same sheet of music: >> >> --enable-opal-progress-threads: enables progress thread machinery in opal >> --> this is just a renaming from --enable-progress-threads >> --> the corresponding #define stays the same: OPAL_ENABLE_PROGRES_THREADS >> >> --enable-opal-multi-threads: enables multi threaded machinery in opal >> --> this is just a renaming from --enable-mpi-threads >> --> the corresponding #define also renames; from OPAL_ENABLE_MPI_THREADS to >> OPAL_ENABLE_MULTI_THREADS >> >> --enable-mpi-thread-multiple: enables the use of MPI_THREAD_MULTIPLE; *ONLY* >> affects the MPI layer >> --> use of this switch explicitly implies --enable-opal-multi-threads >> --> new #define: OMPI_ENABLE_THREAD_MULTIPLE >> >> We can keep and deprecate the old configure options if desired: >> >> --enable-mpi-threads: deprecated synonym for --enable-mpi-thread-multiple >> --enable-progress-threads: deprecated synonym for >> --enable-opal-progress-threads >> >> ..although I'm somewhat inclined to ditch them unless someone has strong >> feelings about keeping them. >> >> Doing the name change in OPAL and ORTE is fairly straightforward -- it's >> essentially an s/foo/bar/g kind of operation. It'll likely take a little >> more effort in the MPI layer because the places where the current #defines >> are used may need to switch to the new name or to the new >> OMPI_ENABLE_THREAD_MULTIPLE name (and maybe some new logic? I am not sure >> without looking into it closer). >> >> > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
