"Jonathan Amsterdam" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I think there's a slight design flaw in the Queue class that makes it > hard to avoid nested monitor deadlock. The problem is that the mutex > used by the Queue is not easy to change. You can then easily get > yourself into the following situation (nested monitor deadlock): > > Say we have a class that contains a Queue and some other things. The > class's internals are protected by a mutex M. Initially the Queue is > empty. The only access to the queue is through this class. > > Thread 1 locks M, then calls Queue.get(). It blocks. At this point the > Queue's mutex is released, but M is still held. > > Thread 2 tries to put something in the Queue by calling the enclosing > class's methods, but it blocks on M. Deadlock. > This isn't really a deadlock, it is just a blocking condition, until Thread 1 releases M.
There are 3 requirements for deadlock: 1. Multiple resources/locks 2. Multiple threads 3. Out-of-order access You have definitely created the first two conditions, but the deadlock only occurs if Thread 2 first acquires the Queue lock, then needs to get M before continuing. By forcing all access to the Queue through the class's methods, which presumably lock and unlock M as part of their implementation, then you have successfully prevented 3. No deadlocks, just proper blocking/synchronization. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
