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


Reply via email to