I'm sure someone will object to a name, but the logic looks fine to me
On Feb 9, 2010, at 6:35 AM, Jeff Squyres wrote:
> On Feb 9, 2010, at 4:34 AM, Ralph Castain wrote:
>
>>> While we're at it, why not call the option giving MPI_THREAD_MULTIPLE
>>> support --enable-thread-multiple ?
>>
>> Ma
On Feb 9, 2010, at 4:34 AM, Ralph Castain wrote:
> > While we're at it, why not call the option giving MPI_THREAD_MULTIPLE
> > support --enable-thread-multiple ?
>
> Makes sense to me. I agree with Brian that we need three options here.
Ok, how about these:
--enable-opal-progress-threads: en
On Feb 9, 2010, at 1:44 AM, Sylvain Jeaugey wrote:
> While we're at it, why not call the option giving MPI_THREAD_MULTIPLE support
> --enable-thread-multiple ?
Makes sense to me. I agree with Brian that we need three options here.
>
> About ORTE and OPAL, if you have --enable-thread-multiple=
While we're at it, why not call the option giving MPI_THREAD_MULTIPLE
support --enable-thread-multiple ?
About ORTE and OPAL, if you have --enable-thread-multiple=yes, it may
force the usage of --enable-thread-safety to configure OPAL and/or ORTE.
I know there are other projects using ORTE an
Well, does --disable-multi-threads disable progress threads? And do you want
to disable thread support in ORTE because you don't want MPI_THREAD_MULTIPLE?
Perhaps a third option is a rational way to go?
Brain
On Feb 8, 2010, at 6:54 PM, Jeff Squyres wrote:
> How about
>
> --enable-mpi-thr
How about
--enable-mpi-threads ==> --enable-multi-threads
ENABLE_MPI_THREADS ==>ENABLE_MULTI_THREADS
Essentially, s/mpi/multi/ig. This gives us "progress thread" support and
"multi thread" support. Similar, but different.
Another possibility instead of "mpi" could be "concurrent
Ah, thanks!
I think what Jeff proposed would retain this behavior - two switches, either of
which enable thread support. Only question really was to rename the
--enable-mpi-threads so it more accurately reflects what it does - namely, to
enable-thread-support internal to the OMPI code base.
Pr
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
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
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
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
11 matches
Mail list logo
