Welcome to the second ‘Can You Spot the Deadlock?’ trivia. I surely hope you had fun with the first one. Yeah, I know, it was kinda easy. So today, I raise the bar a bit and bring you one of my favorites: the transactional subscription/un subscription pattern.
The code compiles but it will not run, as I did not show the scaffolding code. Suffice to say that there is a notification mechanism that lives in its own thread(s) and some client code logic that rely on the main(starting) thread.
As promised, here is the answer to my question
Here the deadlock manifests itself as the main thread stuck on one of the Thread.Join calls and the associated thread’s (_firstRunner or _secondRunner) Monitor.Wait(_synchro) call.
The problem lies with the Monitor.Pulse(_synchro) call, because it wakes onlyone thread waiting allowing it to end properly. The other thread is still waiting for a signal that will never happen. And ultimately, the main thread is waiting for both threads to end, and we already know that it will not happen.
How to fix: you need to replace Monitor.Pulse(_synchro) by Monitor.PulseAll(_synchro).
This example reminds us that deadlocks do not systematicaly occurs on lock statement and that one must be careful regarding thread termination. Plus, here the problem does not relate to the classical ordering of resource acquisition.
The only random aspect was which of the two runner threads would be locked.
It also raises concern about when and why someone has to worry about using Pulse or PulseAll.
How can it be improved: there is a call to Thread.Sleep that I did place just to make sure that both runner thread where waiting for the signal. This is never the proper way to make a rendez-vous point between threads. But this is neither a trivial matter and adequate rendez-vous code would add a significant chunck of code.
Rendez-vous will probably a topic for another exercise.