[Mpi-forum] MPI_Win_lock_all() ordering question

[Jim Dinan]

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 <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
> 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
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20130717/6add2021/attachment-0001.html>