Queue can result in nested monitor deadlock

[Paul McGuire]

"Jonathan Amsterdam" <jbamsterdam at gmail.com> wrote in message
news:1145284326.177062.230120 at v46g2000cwv.googlegroups.com...
> 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