Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: s/ENABLE_MPI_THREADS/ENABLE_THREAD_SAFETY/g
From: Barrett, Brian W (bwbarre_at_[hidden])
Date: 2010-01-28 22:23:02


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
>>> jsquyres_at_[hidden]
>>> <opal-thread-safety.diff>_______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>> --
>> Brian W. Barrett
>> Dept. 1423: Scalable System Software
>> Sandia National Laboratories
>>
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

--
  Brian W. Barrett
  Dept. 1423: Scalable System Software
  Sandia National Laboratories