This should probably more properly be called a "thread interaction test".  The idea is that there is a class of bugs in multithreaded systems that can only be found when multiple threads interact inside a single component.  For instance, you might only see certain data corruption errors when two threads simultaneously write to shared data.  Or you might only see performance problems when you run multiple threads through a component because of synchronization.

When I'm writing multithreaded code (e.g. in most of J2EE) I always plan for this kind of test -- I've just seen too many problems as a result of not planning for this.

KyleBrown

-----
How do you test (or plan to do so) for ThreadBugs? What ThreadTests would you write to ensure that nothing like the following happens:

Thread 1 contains
    A.lockResource()
    B.lockResource()
    ...
    B.unlockResource()
    A.unlockResource()
and Thread 2 contains
    B.lockResource()
    A.lockResource()
    ...
    A.unlockResource()
    B.unlockResource()

''There are tools which generate graphs to find deadlocks, such as the above code would generate.  One of these tools is called VeriSoft.''

Do you have a URL available? I'd like to check which kinds of locks this tool can handle: monitor-style locks, semaphores, etc. It would come in very handy. Actually, even a good notation for these kinds of diagrams would help, but up to now I did not come across such a thing.

BTW, http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html by DougLea implements several important synchronisation schemes.

Personally, I found PetriNet''''''s to be very useful for getting an intuition of possible effects in concurrent programs, but I feel that there is something additional required for describing the static aspects of a concurrent system. -- OlafKummer

-----

That's a very good question.  Personally, I don't think that either formal analysis or tools will completely solve the problem, although there is a time and a place for both.  Usually, I take a very pragmatic approach and simply say "Try the thing with a lot of threads running through it" under what you should believe to be reasonable circumstances.

----
See also ParalleliZation

CategoryTesting