As I mentioned in an earlier posting I’ve been working on a tool this week. I’m too lazy to do a job manually and so I decided to write a tool to help me do it…
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
The tool is designed to help me track down deadlocks in code. I decided I needed this tool because I wrote a piece about debugging deadlocks in Visual C++ and realised that using trial and error to locate deadlocks in some client code simply wasn’t good enough.
It must be a deadlock kinda day. Pete McKinstry points to a Java deadlock avoidance scheme which involves knowing and using a total ordering of the locks that you wish to acquire. This is similar to Andrei Alexandrescu’s C++ idea of always acquiring multiple locks in increasing memory address order.
Both of these are fine if you can get at all of the locks from one place. I find that that’s rarely the case and more often the locks are within objects and I don’t want to break the encapsulation to expose the need to lock around a method so that I can grab the lock that’s inside of the object and then use it from outside of the object in some multiple lock, deadlock avoidance, total ordering, code based lock scheme… In my opinion these ideas are all well and good in theory but just don’t tend to work in practice if you are working with properly factored code….
I’m currently adding some functionality to a server that I wrote, using The Server Framework, for a client last year. The server provides application gateway services for them. The new functionality is to switch to using asynchronous connect calls using ConnectEx when it’s available on the platform that the server is running on and to continue to use a blocking connect if ConnectEx isn’t available.
As I mentioned in the posting back in Feb 2004 the performance counters that we add to these kinds of servers are invaluable in tracking down problems.
I’ve been splunking around Dll loading recently for a pet project. It’s been an interesting journey and this evening I solved the final piece of the puzzle and, when I did, I suddenly wondered, not for the first time, why Windows holds the loader lock when calling DllMain()…
Chris Brumme explains this much better than me, but; the loader lock is a system wide lock that’s held by the OS when it does stuff to its internal process tables; things like loading and unloading Dlls.
I had one of those “Doh!” moments yesterday. In summary, always put the performance monitoring code in early, looking at a program’s vital signs as a jiggly graph can show up all kinds of unexpected things…
The work on the gateway server that I’m currently building for a client has been going well but yesterday I had a weirdness develop. Very rarely a test would fail because the server would fail to respond to a request.
