Recommended Approach For Testing Threads

[Michael Vargenstien]

Hello Everybody,

Is there any recommended strategies for testing you code to make sure that its thread safe? I've been working on the backend database components and am nearing my close. Since threading is major in real life and in the assignment (the reasons for doing this in the first place), what can I do to either identify areas where corruption can occur or simulate a situation which threading may not be 100% thread safe. I don't want to lose marks cause they're hard to come by from what it sounds!!

[Rudolph Jen]

I used the Observer-Pattern, to test my implementation of the provided DB interface: Each Thread get registered as an topic to my observer and the observer gets updated when a status of a registered thread changed (e.g. "tries to get lock", "got lock", "unlock", ..). The observer checks for each update, that e.g. only one threads holds a lock for an recNo. The test isn't finished, until all Thread finished.

Best regards,
R

PS: General MultiThread-Testing for junit: http://groboutils.sourceforge.net/ OR junit4
[ January 29, 2007: Message edited by: Rudolph Jen ]

[Michael Vargenstien]

Thanks Rudolph for your response. Honestly I'm a bit new to the whole Junit thing but I know its a skill that is more then necessary. As for the observer pattern, I'll also look into using that. The sad thing is, the probability that something happens may be very minor but the reality is that it still counts agianst you on the project and in real life. Do you know of any open source tools like junit which might catch things like this or did we just come up with a patent? c l!!

[Rudolph Jen]

>Do you know of any open source tools like junit which might catch things like this or did we just come up with a patent?

Tools like groboutils or junit are only frameworks to support you building your own tests. These frameworks are no brain-machine that can look at your code and generate all needed test by themselves (would be nice). It always the same in software development.

Therefor you always have to design your test suite to get all covered up, where design patterns can be helpful. There are some commercial tools out there that should be handy, but there I have no experience. Until today I do handworking.

Best Regrads,
R

[Eamonn O'Connell]

I find TestNG to be very handy for multi-threaded testing

see homepage for more

[Liviu Carausu]

Hi Michael,
Try to take a look in Java Concurrency in Practice of Brian Goetz. It has a full Testing Concurrent Programs chapter. Try to read also this article TestingConcurrentArticle

Good luck !

[Rob Cromley]

For me, the best approach was to spawn-off 100 threads each trying to lock the same record. Each thread would try for the lock, then when it got it wait for a second before releasing it. I also had a synchronized method that wrote a brief message to sysout and counted the locks (to verify that it happened correctly 100 times).

Hopefully this helps.

[Ken Boyd]

Originally posted by Rob Cromley:
For me, the best approach was to spawn-off 100 threads each trying to lock the same record. Each thread would try for the lock, then when it got it wait for a second before releasing it. I also had a synchronized method that wrote a brief message to sysout and counted the locks (to verify that it happened correctly 100 times).

Hopefully this helps.

Is it possible for you to post testing code?? I had another thread open for that without any reply. (Andrew said it is okay to post test code on forum)

Thanks

[Mihai Radulescu]

Hi Guys

One of the most important thing in the multithread programming is that all the involved threads ends (after they complete them task), if at least one thread remains hanging (or it ends premature) then we have a problem.

For this I build a counter, this is a class which run in its own thread and counts how many times a certain method (the hit method) is called.
Is important to know that the counter threads waits until its hit method was called for a specified number of times.
Each thread to test triggers the hit method before it ends its task and because the counter threads waits until its hit method was called for a specified number of times the test is successful only if the counter thread ends.
To test just spawn a number of threads, build a counter with the number of count equal with the number of spawned threads and let the threads "hit" the counter - if at the end the counter still waits for threads that means one if your threads :
1.is still hanging around
2.is dead prematurely - before it fulfills its tasks.

You can repeat the test in a lot of variations.

Regards,
M

P.S don't forget to test how your lock manager reacts on interrupted threads. You can do this also with the counter.
[ April 30, 2007: Message edited by: Mihai Radulescu ]