1
1
openmpi/ompi/op
Jeff Squyres 23ab9e0277 A better solution to the previous commit -- RETAIN/RELEASE the MPI_Op
at the top-level MPI API function.  This allows two kinds of
scenarios:

1. MPI_Ireduce(..., op, ...);
   MPI_Op_free(op);
   MPI_Wait(...);

For the non-blocking collectives that we're someday planning -- to
make them analogous to non-blocking point-to-point stuff.

2. Thread 1:
   MPI_Reduce(..., op, ...);
   Thread 2:
   MPI_Op_free(op);

Granted, for #2 to occur would tread a fine line between a correct and
erroneous MPI program, but it is possible (as long as the Op_free was
*after* MPI_reduce() had started to execute).  It's more realistic
with case #1, where the Op_free() could be executed in the same thread
or a different thread.

This commit was SVN r7870.
2005-10-25 19:20:42 +00:00
..
Makefile.am The next in a long line of crazed build system changes from Brian. This was 2005-10-17 00:21:10 +00:00
op_predefined.c Correct a few #if issues that George identified in a code review 2005-10-12 13:19:46 +00:00
op_predefined.h Correct a few #if issues that George identified in a code review 2005-10-12 13:19:46 +00:00
op.c Ensure to OBJ_DESTRUCT to free memory during finalize (caught by 2005-10-25 17:27:58 +00:00
op.h A better solution to the previous commit -- RETAIN/RELEASE the MPI_Op 2005-10-25 19:20:42 +00:00