Thanks George,
i understand the change you suggest will fix the test.
tasks will no more fight for the same lock, and i believe that was the
initial intent of the test
(e.g. will task 2 wait for task 0 to release the lock before MPI_Put() data)
but since there is no other way to test
Paul,
SIGSEGV is always a bad idea, even after having displayed a
comprehensive and user friendly error message
--
MCA framework parameters can only take a single negation operator
("^"), and it must be at the beginning
Paul,
short answer, i have no clue.
that being said, consider the following simple program
program test_mpi_sizeof
implicit none
include 'mpif.h'
integer i
double precision d
integer sze,ierr
call MPI_Sizeof(i, sze, ierr)
write (*,*) 'MPI_Sizeof(integer) = ', sze
call MPI_Sizeof(d, sze,
Gilles,
I looked at the test and I think the current behavior is indeed correct.
What matters for an exclusive lock is that all operations in an epoch
(everything surrounded by lock/unlock) are atomically applied to the
destination (and are not interleaved with other updates). As Nathan stated,
To be safe I would call MPI_Get then MPI_Win_flush. That lock will always be
acquired before the MPI_Win_flush call returns. As long as it is more than 0
bytes. We always short-circuit 0-byte operations in both osc/rdma and osc/pt2pt.
-Nathan
> On Nov 21, 2016, at 8:54 PM, Gilles Gouaillardet
Thanks Nathan,
any thoughts about my modified version of the test ?
do i need to MPI_Win_flush() after the first MPI_Get() in order to
ensure the lock was acquired ?
(and hence the program will either success or hang, but never fail)
Cheers,
Gilles
On 11/22/2016 12:29 PM, Nathan Hjelm
True. The lock itself is not an RMA operation so I am not sure if it is
supposed to complete with flush. He may have to initiate an RMA operation to
get the semantics desired.
I do think osc/pt2pt will still flush and wait for the lock message. The
semantics are not wrong but could be more
Why is MPI_Win_flush required to ensure the lock is acquired ? According to
the standard MPI_Win_flush "completes all outstanding RMA operations
initiated by the calling process to the target rank on the specified
window", which can be read as being a noop if no pending operations exists.
MPI_Win_lock does not have to be blocking. In osc/rdma it is blocking in most
cases but not others (lock all with on-demand is non-blocking) but in osc/pt2pt
is is almost always non-blocking (it has to be blocking for proc self). If you
really want to ensure the lock is acquired you can call
Nathan,
we briefly discussed the test_lock1 test from the onesided test suite
using osc/pt2pt
https://github.com/open-mpi/ompi-tests/blob/master/onesided/test_lock1.c#L57-L70
task 0 does
MPI_Win_lock(MPI_LOCK_EXCLUSIVE, rank=1,...);
MPI_Send(...,dest=2,...)
and task 2 does
Dear Open MPI developer,
QE is an MPI program, cf.
http://qe-forge.org/gf/download/frsrelease/224/1044/qe-6.0.tar.gz
In FFTXlib a questionable source code part is contained which cannot be compiled
using version 17 of the Intel compilers and Open MPI; I've condensed it (see
attachment).
11 matches
Mail list logo
