Testing concurrent code question 162 of 180 senior
Why can a unit test not reliably catch a visibility or reordering bug?
- Because JUnit runs tests sequentially
- Correct: Because the synchronisation used to line the threads up is itself a memory barrier that drains the store buffer producing the effect
- Because the JIT does not run in tests
- It can, with enough iterations
To observe a reordering you need two threads executing a few instructions at precisely overlapping moments. Arranging that requires a latch or a barrier, and that construct emits fences and creates happens-before edges, which is exactly what suppresses the behaviour you were trying to see. The test destroys what it measures.
Measured in the sibling repository, the textbook Dekker probe found zero reorderings in 20,000 hand-written attempts and zero in 500,000 barrier-synchronised iterations. jcstress found 9,914,377 in a single run, 3.74% of samples.
The conclusion to state plainly: absence of failure in a concurrency test is not evidence of correctness. Correctness here comes from reasoning about happens-before, and from tools built for the job.
Quiz yourself on Testing concurrent code Suggest a correction