Interesting article on deadlock detection in DDJ this month

| 4 Comments

There's an interesting article by Tomer Abramson in this month's Dr Dobb's Journal about deadlock detection. He provides a compile in tool that works in a similar way to my deadlock detection tool and reports on potential deadlocks in code even if they never occur during the program run in question.

His architecture is considerably different to mine but the idea is the same. By recording the sequence of lock acquisition and release on all threads in the program you can then examine the sequence that locks are taken out and spot potential deadlocks.

4 Comments

MS research has a project called Racetrack that does this for managed code using a modified runtime. There is a ppt on there with pointer's to other research projects such as Eraser at IBM.

http://research.microsoft.com/research/sv/racetrack/

I think this is the IBM project they refer to:
http://www.kelehers.org/papers/tpds98.pdf

Steve,

Thanks for the links. Racetrack looks interesting and I guess you can do a lot more by looking at the data access rather than simply the locking (or, I guess, lack of it).

FWIW, this also sparked a discussion (or made an existing discussion take a new turn) on the TDD list on Yahoo!.

Ron Jeffries challenged TDD:ers relying heavily on Mock Objects to build a mock-based test that does deadlock detection.

Some people spoke up, so I thought it might be interesting for you to see what they came up with:

Maillist thread: http://groups.yahoo.com/group/testdrivendevelopment/message/13789
Ayende's proposed solution: http://www.ayende.com/Blog/2005/12/19/MockingChallangeMockingTDDAndMultiThreading.aspx

Looking forward to seeing your app.

- Kim

Thanks Kim, that's interesting stuff.

The problem I find with Ayende's solution is that it's too invasive and requires the user of the locks to 'opt in' to be part of the testing. You need to get your locks from the lock manager, etc...

My tool, being external, doesn't require explicit opt in but also doesn't fit with the TDD style of working - unless you run your test harness inside it; which is a possibility... I've done some work with dynamic mocking of Win32 API functions and that works nicely but I'm not sure who else bothers to test down to that level...

Leave a comment