param says we should Also, check for != 0, rather than == 1, as there
are way too many double locks, but they'll get warned when we do the
double lock. No need to warn again, in a meaningless way.
Originally part of r15167, reverted with r15172.
This commit was SVN r15173.
The following SVN revision numbers were found above:
r15167 --> open-mpi/ompi@faa401dc47
r15172 --> open-mpi/ompi@5f16251808
OBJ_NEW
* Need to single when the passive unlock has left an expose epoch for
the win_free case
* Clean up some debugging output
* fix missing variable initialization
This commit was SVN r15167.
flex (which, incidentally, emit ''more'' warnings than earlier
versions). Grumble.
This commit was SVN r15166.
The following SVN revision numbers were found above:
r15158 --> open-mpi/ompi@57d09c10f7
Ensure that the AM_CONDITIONALs are ''always'' run, even if we
--enable-mca-no-build the paffinity/linux component.
This commit was SVN r15095.
The following Trac tickets were found above:
Ticket 1057 --> https://svn.open-mpi.org/trac/ompi/ticket/1057
single threaded builds. In its default configuration, all this does
is ensure that there's at least a good chance of threads building
based on non-threaded development (since the variable names will be
checked). There is also code to make sure that a "mutex" is never
"double locked" when using the conditional macro mutex operations.
This is off by default because there are a number of places in both
ORTE and OMPI where this alarm spews mega bytes of errors on a
simple test. So we have some work to do on our path towards
thread support.
Also removed the macro versions of the non-conditional thread locks,
as the only places they were used, the author of the code intended
to use the conditional thread locks. So now you have upper-case
macros for conditional thread locks and lowercase functions for
non-conditional locks. Simple, right? :).
This commit was SVN r15011.
re-enabling compilation of this component.
However, it still won't compile because this component provides a
module finalize function which apparently somehow got dropped from the
paffinity base. Support for the paffinity module finalize function
needs to be re-added.
This commit was SVN r14915.
* Enable VPATH builds to work (slight tweak of r14895 -- mainly
because I already had it done when George committed :-) )
* Enable "make dist" to work properly for PLPA included mode
* Update plpa.h.in
* Update svn:ignore
Took relevant changes back to the main PLPA SVN as well.
This commit was SVN r14896.
The following SVN revision numbers were found above:
r14895 --> open-mpi/ompi@bb7b04e875
Changes paffinity interface to use a cpu mask for available/preferred cpus
rather than the current coarse grained paffinity that lets the OS choose
which processor.
Macros for setting and clearing masks are provided.
Solaris and windows changes have not been made. Solaris subdirectory has some
suggested changes - however the relevant man pages for the Solaris 10 APIs
have some ambiguity regarding order in which one create and sets a processor
set. As we did not have access to a solaris 10 machine we could not test to
see the correct way to do the work under solaris.
This commit was SVN r14887.
symbols in them and environ is defined only in the final application
(probably in crt1.o). Apple provides a function for getting at the
environment, so use that instead if it's available.
This commit was SVN r14857.
OPAL and ORTE. Since we now do opal_progress_init(), we do it
there. Fixes a performance issue introduced in r14773.
* While trying to find the above, notived that we did the reference
counting for the init in init_util and for finalize in fini. That
isn't right, so make them both in the non-util versions.
This commit was SVN r14830.
The following SVN revision numbers were found above:
r14773 --> open-mpi/ompi@1e678c3f55
This commit moves the initalization/finalization of opal_event and opal_progress
to opal_init/finalize. These were previously init/final in ORTE which is an
abstraction violation. After talking about it we concluded that there are no
ordering issues that require these to be init/final in ORTE instead of OPAL.
I ran the IBM test suite against this commit and it didn't turn up any new
failures so I think it is good to go.
Let us know if this causes problems.
This commit was SVN r14773.
