FYI (milliways = www.open-mpi.org).
Begin forwarded message:
> From: "Kim, DongInn" <>
> Date: January 28, 2010 3:41:52 PM EST
> Subject: Reboot milliways
>
> Hi,
>
> We need to reboot milliways due to its maintenance on Jan 29th, 2010.
>
> Date: Friday, Jan 29th, 2010
> Time:
> - 5:00am-5:30a
WHAT: Remove the GM BTL and the dr PML
WHY: They're old, dead, and haven't changed in years.
WHERE: ompi/mca/btl/gm and ompi/mca/pml/dr
WHEN: For v1.5
TIMEOUT: COB Fri, 5 Feb 2010
-
MORE DETAIL:
I was trawling through the code base tonight for various insundry reasons and
found that we
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 witho
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
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
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
