I’ve been working on my deadlock detection and lock monitoring tool quite a lot this week; that and fixing the issues that it’s been highlighting. Yesterday I decided that I was drowning in data and that I really needed a GUI and, as I thought about how the GUI should work, I realised that I really didn’t have enough data.
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
My problem was that I was summarising the data as I sampled it. This made it easier to see the information that I wanted to see but made it hard to mix and match the views in the way that I’d like to if I had a nice GUI on top. By summarising at the sampling stage I was throwing away far too much information. Ideally the GUI will allow you to see all of the locks in your process, look at how your threads use the locks, display inappropriate lock sequences and potential deadlocks and allow you to drill down from anywhere to anywhere else. The summarised data that I was collecting earlier in the week made the last part impossible. I’d thrown away too much information whilst getting to a point where I knew the tool worked.
So, for the last day or so I’ve been adjusting my data structures so that I retain all of the information and only summarise at the last possible moment. This should mean that I can drill down much better in the GUI because I’ll have all of the underlying information that I might wish to drill down into. Already the new data structures are showing promise; I can now drill into a lock contention situation and see what happened in both threads either side of the contention; might be useful, perhaps. I can also zoom out from an incident and look at what other threads were doing at around the same time…
I could have built the data structures this way from the start, I guess. But at the start I didn’t know that what I was gathering was so valuable. To be honest, I didn’t know that it would work at all. Now I know what I want and I know how to get it… Engage.