8

Possible Duplicate:
How should I unit test threaded code?
Guidelines for testing multithreaded code or ensuring that code is thread-safe

Is it possible to "unit test" whether a simple class is thread safe or not?

My specific case is a simple class, that subsets vectors: given a "white list" of vector positions to keep and an input vector, it produces an output vector with only the values at the positions in the white list. I'd like to write a unit test (if it is possible) to make sure that if we refactor this class in the future, we keep it thread safe. The unit test would fail if the class is no longer thread safe. I realize this is somewhat vague and under defined.

Improve this question
9
  • Only way to be sure would be to actually run it through some intensive threaded tests designed to catch things like race conditions and dropped values. Commented Aug 20, 2012 at 15:43
  • But would it work reliably, and would the tests fail only sometimes? Commented Aug 20, 2012 at 15:44
  • 5
    You can't prove that a class is thread safe with testing. You can merely try to stress test it, hoping that if you have concurrency bugs, they will show up, but without any guarantee that they will. Commented Aug 20, 2012 at 15:44
  • 1
    possible duplicate of How should I unit test threaded code? and Guidelines for testing multithreaded code or ensuring that code is thread-safe Commented Aug 20, 2012 at 15:45
  • 1
    The problem with unit testing for thread problems is that your test harness virtually always has different timing behavior (and CPU and memory behavior too) than your real application, and thread problems are usually sensitive to such things. This is because things like deadlock-freedom and liveness are global properties, and not (usually) component-level properties. Commented Aug 21, 2012 at 8:01

2 Answers 2

Reset to default
5

Thread-safe is a property that a class has or doesn't have. Thread-safety can mean, depending on the context, absence of race conditions, the execution of code in a particular order or whatever else.

Testing cannot prove the absence of bugs, it can only reveal them. In my (not-so-vast) experience with ensuring that multithreaded code is correct probably the best tip is to keep the code as simple and clear as possible and try to discover bugs by inspection. Repeatedly running tests won't help too much.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

5

This is exactly what Java Pathfinder is for. It has a bit of a steep learning curve, but it's actually possible to build exhaustive proofs with this tool. You build a scenario and run it with JPF, then JPF explores all possible thread orderings to find possible errors. You need to build assertions into your program for JPF to check. JPF assumes sequential consistency during execution, but you can use the Java Racefinder plugin to prove that too.

Admittedly, it's hard to build a proper proof—but it is possible. If nothing else JPF can be used to help you root out some concurrency errors that you might otherwise miss.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.