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).
Posted by: Len at December 24, 2005 11:38 PMFWIW, 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
Posted by: Kim Gräsman at December 27, 2005 01:38 PMThanks 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...