In multithreaded programs error happens when threads accessing fields and monitors in parallel. If everything is accessed sequentially everything works correctly. Only when fields and monitors are accessed in parallel you will see errors. Therefore you must make sure that in your tests fields and monitors are accessed in parallel not only in production. This is what waitpoints are for.
For example the following method will lead to an incorrect count if the field i is accessed in parallel
@RunWith(ConcurrentTestRunner.class)
public class RaceConditionVolatileCounter {
private volatile int i = 0;
@Test
public void addOne()
{
i++;
}
}
You can download the class here RaceConditionVolatileCounter.java
If the field is atomically read and written in a row by each thread seqentially, the sum will be correct. You can see the access pattern in the Access Detail View:
The figure shows the sequentiall read and write of the threads. Each Thread first reads than write the field. The two atomic operations are executed in a row by each thread. Now you can set a waitpoint at the field in the Method Explorer View:
By setting a waitpoint you make sure that a thread waits at the write operation for other threads before executing the operation. This parallelize the read and writes operation, leading to the following execution:
<img alt="vmlens race conditions view" src="../img/help/wait_3.png" class="center-block img-responsive"border="0">
And this leads to an incorrect sum smaller than 4.
With waitpoints, you can parallelize the access to volatile fields, synchronized blocks and methods. You can set waitpoints in the Method Explorer View