Queue can result in nested monitor deadlock

[Paul McGuire]

"Jonathan Amsterdam" <jbamsterdam at gmail.com> wrote in message
news:1145306244.336966.113470 at e56g2000cwe.googlegroups.com...
> This is a reply to Alan Morgan, Paul McGuire and Duncan Booth.
>
> I need mutex M because I have other fields in my class that need to be
> thread-safe.
>
> The reason I want to use a Queue and not a list is that a Queue has
> additional synchronization besides the mutex. For instance, Queue.get()
> will block the caller until the queue is non-empty. Of course I could
> build this behavior on top of a list, but then I'm reinventing the
> wheel: Queue.Queue is the perfect thing, except for the problem I
> describe.
>
> I can't release my mutex M and then call Queue.get().  That could be a
> race condition: between the time M is released and Queue's mutex is
> acquired, another thread could get into my object and mess things up.
> (We'd need a specific example to see this, and there may be many cases
> where I could safely release M before calling Queue.get(), but in
> general it won't work.)
>
What if you expose an unguarded method on your class, that allows external
put()'s to the Queue without first locking M?

-- Paul