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).
Note
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
MPI_Win_lock
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 MPI
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.
George
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 than
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
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
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,
MP
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, ie
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
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 this,
11 matches
Mail list logo