Hi all,
here's another thing making me think. I have designed a framework, which needs testing. So far, i have used UnitTest++[ad], the best C++ unit testing framework i have ever tested (i tested CxxUnit, gtest and UnitTest++)[/ad], and everything works fine.
Now i added multi threading to the framework. Its the first time i *really* (i.e. besides academic examples from lectures) use multi threading. The problem is: How do i test the thing now?
One approach i read about (
http://www.ibm.com/developerworks/java/library/j-contest.html ), goes as follows:
1. Create tests just like normal unit tests.
2. Mock the thread class, the locks and the mutexes.
3. Sequentially execute a randomly chosen, legal (i.e. allowed by thread semantics) sequence of instructions of the test. This sequence of instructions is executed
4. If a test assertion fails, dump the randomly chosen instruction sequence, so the test becomes reproducable.
5. While the test is running, check for deadlocks, potential deadlock locking patterns and such things.
6. As the test will be run several million (or even billion) times, this will probably point out multi threading errors.
This seems to be a good thing, as schedulers might not switch threads in every possible fashion, but will probably switch them in the same way every time the test runs, or in one of few ways.
My question: Is there anything like this approach for C++ and pthread/boost::threads? Is there a better way for testing multi threaded applications?
Cheers, TheBear