Lives in the UK. Likes blogging, cycling and eating lemon drizzle cake. Roger is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

Five Ways of Synchronising Multithreaded Integration Tests

04.25.2013
| 2824 views |
  • submit to reddit

A few weeks ago I wrote a blog on synchronizing multithreaded integration tests, which was republished on DZone Javalobby from where it received a comment from Robert Saulnier who quite rightly pointed out that you can also use join() to synchronize a worker thread and its unit tests. This got me thinking, just how many ways can you synchronise multi-threaded integration tests? So, I started counting... and came up with:

  1. Using a random delay.
  2. Adding a CountDownLatch
  3. Thread.join()
  4. Acquiring a Semaphore
  5. With a Future and ExecutorService

Now, I’m not going to explain all the following in great detail, I’ll let the code speak for itself, except to say that all the code samples do roughly the same thing: the unit test creates a ThreadWrapper instance and then calls its doWork() method (or call() in the case of the Future). The unit test’s main thread then waits for the worker thread to complete before asserting that the test has passed.

For the sample code demonstrating points 1 and 2 take a look at my original blog on Synchronizing Multithreaded Integration Tests, though I wouldn’t recommend point 1: using a random delay.


Thread.join()


public class ThreadWrapper {

  private Thread thread;

  /**
  * Start the thread running so that it does some work.
  */
  public void doWork() {

  thread = new Thread() {

  /**
  * Run method adding data to a fictitious database
  */
  @Override
  public void run() {

  System.out.println("Start of the thread");
  addDataToDB();
  System.out.println("End of the thread method");
  }

  private void addDataToDB() {

  try {
  Thread.sleep(4000);
  } catch (InterruptedException e) {
  e.printStackTrace();
  }
  }
  };

  thread.start();
  System.out.println("Off and running...");
  }

  /**
  * Synchronization method.
  */
  public void join() {

  try {
  thread.join();
  } catch (InterruptedException ex) {
  Thread.currentThread().interrupt();
  }
  }
}


public class ThreadWrapperTest {

  @Test
  public void testDoWork() throws InterruptedException {

  ThreadWrapper instance = new ThreadWrapper();

  instance.doWork();
  instance.join();

  boolean result = getResultFromDatabase();
  assertTrue(result);
  }

  /**
  * Dummy database method - just return true
  */
  private boolean getResultFromDatabase() {
  return true;
  }
}


Acquiring a Semaphore


public class ThreadWrapper {

  /**
  * Start the thread running so that it does some work.
  */
  public void doWork() {
  doWork(null);
  }

  @VisibleForTesting
  void doWork(final Semaphore semaphore) {

  Thread thread = new Thread() {

  /**
  * Run method adding data to a fictitious database
  */
  @Override
  public void run() {

  System.out.println("Start of the thread");
  addDataToDB();
  System.out.println("End of the thread method");
  semaphore.release();
  }

  private void addDataToDB() {

  try {
  Thread.sleep(4000);
  } catch (InterruptedException e) {
  e.printStackTrace();
  }
  }
  };

  aquire(semaphore);
  thread.start();
  System.out.println("Off and running...");
  }

  private void aquire(Semaphore semaphore) {
  try {
  semaphore.acquire();
  } catch (InterruptedException e) {
  e.printStackTrace();
  }
  }
}


public class ThreadWrapperTest {

  @Test
  public void testDoWork() throws InterruptedException {

  ThreadWrapper instance = new ThreadWrapper();

  Semaphore semaphore = new Semaphore(1);
  instance.doWork(semaphore);
  semaphore.acquire();

  boolean result = getResultFromDatabase();
  assertTrue(result);
  }

  /**
  * Dummy database method - just return true
  */
  private boolean getResultFromDatabase() {
  return true;
  }
}


With a Future


public class ThreadWrapper implements Callable<Boolean> {

  @Override
  public Boolean call() throws Exception {
  System.out.println("Start of the thread");
  Boolean added = addDataToDB();
  System.out.println("End of the thread method");
  return added;
  }

  /**
  * Add to the DB and return true if added okay
  */
  private Boolean addDataToDB() {

  try {
  Thread.sleep(4000);
  } catch (InterruptedException e) {
  e.printStackTrace();
  }
  return Boolean.valueOf(true);
  }
}


public class ThreadWrapperTest {

  @Test
  public void testCall() throws ExecutionException, InterruptedException {

  ThreadWrapper instance = new ThreadWrapper();

  ExecutorService executorService = Executors.newFixedThreadPool(1);

  Future<Boolean> future = executorService.submit(instance);

  Boolean result = future.get();

  assertTrue(result);
  }
}

Having listed all these methods, the next thing to consider is which one is the best? In asking that question you have to define the word “best” in terms of best for what? Best for simplicity? Maintainability? Speed or code size? After all Programming the Art of Making the Right Decision. You may have guessed that I don’t like the random delay idea and prefer the use of a CountDownLatch. Thread.join() is a bit old school; remember that the likes of Semaphore and CountDownLatch were written to improve on the original Java threading techniques. ExecutorService seems a little heavy weight for what we need here. At the end of the day the choice of technique really comes down to personal preference.

Finally, I’ve listed five ways of synchronizing multi-threaded integration tests; however, if you can think of any others please let me know...

The source code for this blog is available on Github.
Published at DZone with permission of Roger Hughes, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Robert Saulnier replied on Thu, 2013/04/25 - 8:56am

Thanks for the mention. I'll have to show this to my girlfriend to let her know that I'm right sometimes.

Here are a few more old school options for your list. All of them better than option 1, but worse than options 2 to 5.

6. Polling volatile boolean (with sleep)

7. Classic wait-notify

8. Using a Lock instead of option 7

Attila-mihaly Balazs replied on Sun, 2013/07/07 - 2:33pm

I would like to mention a sixth way: http://www.transylvania-jug.org/archives/5442

It is based on the idea of counting when the entering/exiting into a method occurs and waiting until we "exited" all the methods (regardless of the thread).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.