A sneak Preview of Typemock Racer : Thread Deadlock Finder

My blog has moved. You can view this post at the following address: http://www.osherove.com/blog/2008/7/8/a-sneak-preview-of-typemock-racer-thread-deadlock-finder.html
Published Tuesday, July 8, 2008 11:42 AM by RoyOsherove

Comments

Tuesday, July 8, 2008 12:19 PM by Vadim

# re: A sneak Preview of Typemock Racer : Thread Deadlock Finder

Cannot wait to start playing with Typemock Racer.  Is released version going to be free?

Wednesday, July 9, 2008 5:16 PM by Avish

# re: A sneak Preview of Typemock Racer : Thread Deadlock Finder

Very cool, and addressing an important problem. Kudos! I have a few questions, however:

"To reproduce this result..." - you mean that by just running the test again, it won't be reproduced?

It seems like ThreadTest simulates execution of different blocks (delimited by lock boundaries) from different threads in every possible order, until it detects a deadlock. If this assumption is correct, then:

1. Does the SpecificScenario attribute tell ThreadTest to try that particular order first?

2. Doesn't the number of permutations grow exponentially with the number of locks or threads? How does TypeMock Racer perform with real codebases?

Thursday, July 10, 2008 4:30 AM by RoyOsherove

# re: A sneak Preview of Typemock Racer : Thread Deadlock Finder

avish:

1. you are correct. it will start with the failing scenario first, which is good for debugging purposes.

2.The number of permutations does grow almost exponentially at some cases. there are various heuristics that are taken but tests with many threads and many locks will almost always perform slower that simpler ones. since this is an integration testing framework, tests may take longer. I will show some more complex examples later on.