Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Say you have a function f that is or contains a critical section. How would you unit test that only one thread can run it at once, that it doesn't have race conditions, and that it doesn't cause a deadlock, etc...?

share|improve this question
-1 "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much." (Programmers FAQ) – gnat May 22 '12 at 7:25
there does exist tools like CHESS that "systematically enumerates the possible thread schedules to find hard-to-find concurrency errors, including assertion violations, deadlocks, data-races, and atomicity violations." However as @DeadMG points out, any tool that do this can only fail to find a defect, not actually ensure that there are no defects – Conrad Frix May 23 '12 at 21:00
@ConradFrix - I don't really agree that testing is about verification that something works. I take a sort of scientific approach to in and so follow the philosophies of Karl Popper on the matter: testing is about trying to break code. In other words, my code becomes sort of my working theory and my tests are my attempts to falsify that theory. A theory that remains unfalsified is not proven to be correct, it's only proven not to be incorrect wrt the current understanding. I simply NEVER use tests as "proof" that my code is bug free. That would be kind of silly I think. – Crazy Eddie May 24 '12 at 0:57
@crazy eddie I don't disagree with you and I don't know what I said that led you to belive that I felt differently, but ok. – Conrad Frix May 24 '12 at 1:15

You can't. Testing can only prove that you didn't find any bugs, not that none exist, and in the presence of multi-threaded code, I would say that it's almost pointless. You cannot test for how your function behaves when the OS changes it out or pauses execution or any of a thousand external events which can affect when the thread is scheduled and it's behaviour.

You need to, at least informally, prove the function correct.

share|improve this answer

You cannot do a "strong" test, but you can mitigate some risk by doing a "weak" test.

Parameterize f to take some additional code if passed in. Then in the test, pass code for a thread counter, a sleep and an assertion that the thread counter never got above 1. When running the test I would use 5-10 threads. I would also restructure a function without a critical section and make sure the thread counter got above 1. The idea would be to make sure the serialization was a result of the critical section only.

share|improve this answer

Add sleeps around operations within f and add a parameter to let you control their length. You can then unit test as normal, but with different scheduling patterns.

share|improve this answer

TDD is useless in multi-threaded scenarios. You don't test thread safety, you prove it, or it counter-proves you, painfully...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.