Joining Threads vs. Monitors

I currently expire unexpected dead-locks within some trivial C# code.
Now I wonder if it is expected behaviour, that monitors do no wake up,
when the thread previously owning the monitor class class Join on the
thread waiting for the monitor? Simplified the code I have looks like this:

class DeadLock
{
object mutex = new object();
Thread thread = null;

void Start()
{
thread = new Thread(Worker);
thread.Start();
}

void Cancel()
{
lock(mutex) { /* ... */ }
thread.Join();
}

void Worker()
{
/* ... */
lock(mutex) { /* ... */ }
}
}

When calling Cancel before Worker reaches its critical section I
observe, the following:

- Cancel acquires the monitor and enters its section
- shortly later Worker tries to get the same monitor and blocks
- Cancel releases the monitor and calls waits for Worker to terminate
- Worker never gets be monitor, if I do not manually kill Cancel

I really do not understand, what causes this dead-lock in .NET 2.0.

>
Mathias Hasselmann wrote:

>I currently expire unexpected dead-locks within some trivial C# code.
Now I wonder if it is expected behaviour, that monitors do no wake up,
when the thread previously owning the monitor class class Join on the
thread waiting for the monitor? Simplified the code I have looks like this:

Lock and Join should not affect each other.

To find such issues quicker next time I wonder if .NET provides
utilities like ThreadMXBean#findMonitorDeadlockedThreads()[1], which are
quite helpful for finding monitor dead-locks?