Provoking a race condition in Java

Question

I got to write a unit test which provokes a race condition so I can test if I probably fixed the problem later on. The problem is that the race condition only occurs very rarely, maybe because my computer has only two cores.

The code is something like the following:

class MyDateTime {
  String getColonTime() {
    // datetime is some kind of lazy caching variable declared somewhere(does not matter)
    if (datetime == null) {
      initDateTime(); //Uses lazy to initlialize variable, takes some time
    }
    // Colon time stores hh:mm as string
    if (datetime.colonTime == null) {
      StringBuilder sb = new StringBuilder();
      //Now do some steps to build the hh:mm string
      //...
      //set colon time
      datetime.colonTime = sb.toString();
    }
  return datetime.colonTime;
  }
}

Explanation: initDateTime assigns a new instance to dateTime, therefor, datetime.colonTime is null afterwards (as we want to initialize it lazy, as I stated before). Now if Thread A enters the method and then the scheduler stops it just before it can run initDateTime(). Thread B now runst getColonTime(), sees that datetime is still null and initialzes it. datetime.colonTime is null so the second if block is executed and datetime.colonTime gets the value of the StringBuilder. If then the scheduler stops the thread between this line and the return statement and resumes thread A, the following happens: As A was stopped just before initDateTime is called, A now calls initDateTime(), which will kind of reset the datetime object, setting datetime.colonTime to null again. Thread A then will enter the second if block, but the scheduler will interrupt A before datetime.colonTime = sb.toString(); is called. As a conclusion, dateTime.colonTime is still null. Now the scheduler resumes B and the method returns null.

I tried to provoke the race condition by having a number of threads calling getColonTime() to a single (final) instance of MyDateTime, but it only fails in some extreeemly rare cases :( Any hints how to write a JUnit "test"?

Answer 1

As you mention, race conditions are exceedingly difficult to reproduce consistently. However, the law of averages is on your side. If you create a test that you expect to fail maybe one in a hundred times, and then make it happen a thousand times, you'll probably catch the error fairly consistently in your old code. So, in keeping with TDD principles, you should start with the code the way it was before, come up with a test iterates enough times to fail consistently against the old code, then change to your new code and make sure it doesn't fail.