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 and OPAL, but the vast majority
of users are still using OMPI and were already confused by
--enable-mpi-threads. Switching to --enable-multi-threads or
--enable-thread-safety will surely confuse them one more time.
Sylvain
On Mon, 8 Feb 2010, Barrett, Brian W wrote:
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-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".
On Jan 28, 2010, at 9: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
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
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
