Question: I am investigating the design of a work queue processor where the QueueProcessor retrieves a Command Pattern object from the Queue and executes it in a new thread.

I am trying to get my head around a potential Queue lockup scenario where nested Commands may result in a deadlock.

E.G.

A FooCommand object is placed onto the queue which the QueueProcessor then executes in its own thread.

The executing FooCommand places a BarCommand onto the queue.

Assuming that the maximum allowed threads was only 1 thread, the QueueProcessor would be in a deadlocked state since the FooCommand is infinitely waiting for the BarCommand to complete.

How can this situation be managed? Is a queue object the right object for the job? Are there any checks and balances that can be put into place to resolve this issue?

Many thanks. ( application uses C# .NET 3.0 )

Answer: 
For simple cases like this an additional monitoring thread that can spin off more threads on demand is helpful.

Basically every N seconds check to see if any jobs have been finished, if not, add another thread.

This won't necessarily handle even more complex deadlock problems, but it will solve this one.

My recommendation for the heavier problem is to restrict waits to newly spawned process, in other words, you can only wait on something you started, that way you never get deadlocks, since cycles are impossible in that situation.
If you are building the Queue object yourself there are a few things you can try:

1. Dynamically add new service threads. Use a timer and add a thread if the available thread count has been zero for too long.
2. If a command is trying to queue another command and wait for the result then you should synchronously execute the second command in the same thread. If the first thread simply waits for the second you won't get a concurrency benefit anyway.