Thanks. Searching the tickets just now, I found #363. Are my issue and that ticket related? https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/363 On 07/17/2013 10:54 AM, Jim Dinan wrote:

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] <mailto:[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] <mailto:[email protected]> http://lists.mpi-forum.org/__mailman/listinfo.cgi/mpi-forum <http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum>

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- Michael A. Raymond SGI MPT Team Leader (651) 683-3434