[Mpi-forum] MPI_Win_lock_all() ordering question
james.dinan at gmail.com
Wed Jul 17 10:54:35 CDT 2013
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
On Wed, Jul 17, 2013 at 11:41 AM, Michael Raymond <mraymond at sgi.com> 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
> 0 1
> MPI_Win_lock(EXCLUSIVE, 0)
> MPI_Win_lock(EXCLUSIVE, 1) MPI_Win_lock_all()
> .... ....
> MPI_Win_unlock(1) MPI_Win_unlock_all()
> 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
> mpi-forum at lists.mpi-forum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mpi-forum