Queue can result in nested monitor deadlock

[Piet van Oostrum]

>>>>> "Paul McGuire" <ptmcg at austin.rr._bogus_.com> (PM) wrote:

>PM> "Jonathan Amsterdam" <jbamsterdam at gmail.com> wrote in message
>PM> news:1145292096.906390.254280 at e56g2000cwe.googlegroups.com...
>>> If you don't want to call it deadlock, fine, but the program execution
>>> I describe will make no progress to the end of time. Thread 2 can never
>>> put anything in the queue, because Thread 1 holds M, and Thread 1 will
>>> never release M because that can only happen if someone puts something
>>> on the queue.
>>> 

>PM> Ah, I get it now, and yes as you describe it, this is a deadlock.  But why
>PM> do you need both mutex M and a Queue, then?  You should release M before
>PM> calling Queue.get().  Then if you need to, you should reacquire it
>PM> afterward.

What Jonathan says is that in his example M and the mutex for the Queue
should be the same to solve the problem. And that the Queue API should
allow you to do that. I think he is right.
-- 
Piet van Oostrum <piet at cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet at vanoostrum.org