Hi Michael, This believe that this can deadlock. I agree that it's unfortunate that we didn't call it out in the spec, given that it would help to clarify the intended semantics. ~Jim. On Wed, Jul 17, 2013 at 11:41 AM, Michael Raymond <[email protected]> wrote:
I've got a question about the use of MPI_Win_lock_all() in the face of competing MPI_Win_lock(EXCLUSIVE) calls. Consider the following calls sequence:
0 1 MPI_Win_lock(EXCLUSIVE, 0)
MPI_Win_lock(EXCLUSIVE, 1) MPI_Win_lock_all()
.... .... MPI_Win_unlock(1) MPI_Win_unlock_all() MPI_Win_unlock(0)
In this situation 0 has an exclusive lock on itself. Simultaneously, 0 tries to get 1 exclusively and 1 tries to get a shared lock on everyone. If 0 gets lucky, it will get to go first and everything will go fine. If OTOH 1 locks itself shared and then tries to lock 0 shared, deadlock ensues. You could argue that there should be some global queue / governor that lets 0 go first, but then I could see running into scalability problems.
I can't find any place in the standard that says if the user shouldn't do this, or if deadlock is allowed, or if the MPI implementation should figure things out on its own. Thoughts?
-- Michael A. Raymond SGI MPT Team Leader (651) 683-3434
______________________________**_________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum>