functions MPI_Test, MPI_Testany, MPI_Wait, MPI_Waitany
should not reset the status.MPI_ERROR as passed by user.
- This needed implementing the MPI_Waitsome and MPI_Testsome.
This commit was SVN r10980.
MPI_WAIT, MPI_TEST, MPI_WAITANY, and MPI_TESTANY. It isn't really
clear what the standard wants as the return code for these functions,
and this is what Sun MPI, LAM/MPI, and MPICH2 all do.
Fixes trac:172
This commit was SVN r10872.
The following Trac tickets were found above:
Ticket 172 --> https://svn.open-mpi.org/trac/ompi/ticket/172
to let the PML (or io, more generally the low level request manager)
to have it's own release function (what was before the req_fini). This
function will only be called from the low level while the req_free will
be called from the upper level (MPI layer) in order to mark the request
as not used by the user anymore.
From the request point of view the requests will be marked as inactive
everytime we read their status (true for persistent as well). As
MPI_REQUEST_NULL is already marked as inactive, the test and wait functions
are simpler. The drawback is that now we have to change in the
ompi_request_{test|wait} the req_status of the request once we get it's
status.
This commit was SVN r9290.
- initial support for gm progress thread
- corrected threading issue in pml
- added polling progress for a configurable number of cycles to wait for threaded case
This commit was SVN r9188.
- move files out of toplevel include/ and etc/, moving it into the
sub-projects
- rather than including config headers with <project>/include,
have them as <project>
- require all headers to be included with a project prefix, with
the exception of the config headers ({opal,orte,ompi}_config.h
mpi.h, and mpif.h)
This commit was SVN r8985.
know that the request is inactive we don't have to call fini). Remove if's from
the critical path. Change a do in while to make sure we do the minimum in all cases.
All in all it decrease the latency for mvapi by something between 0.15 and 0.20
micro-seconds. But it's just a first step ...
This commit was SVN r8770.
thread finish a request between the moment when we check the request status and the moment
when we acquire the lock, and if there are no more pending request on the pipe we will be
stuck foreverr as nobody have any reason to broadcast the request condition. I check the
req_any and it doesn't contain the same bug.
This commit was SVN r8760.
- Test for MPI_REQUEST_NULL within the often executed loop not
necessary, but left as a comment
- The req_fini may potentially return an error, do check for it in
req_wait.
This commit was SVN r8488.
