Question

I recently had to complete one of these job interview coding exercises. Basically it required implementing a message queue class that:

• maintains items based on a priority field in the incoming message.
• the message can be in one of three priority categories high, medium, low controlled via message.priorityField value range.
• has a getSize and isEmpty methods.
• has a place(message) method.
• has a remove method.
• has getFront() method (which returns highest priority message)

What I did in the end without going into too much detail is implement a MessageQueue class that internally uses ConcurrentSkipListMap (a concurrent and ordered map) to hold the messages.

I also implemented a basic JUnit test case that tests for basic business requirements.

Now as its a messaging queue and hence messages can come in concurrently of course I need to test the occurrent aspect of the implementation.

I’m getting closer to the heart of the question now.

My thinking is that the basic JUnit test case should verify the code works when a single thread is interacting with the implementation.

I then implemented a concurrent test case which should verify the occurrent aspect of the implementation.

Now here is the question:
What concurrent aspects should I be testing for?

The only thing I can think of is having multiple producer threads that inject methods in the queue and multiple consumer threads that remove the messages (via getFront()) .
What is being verified here is that whatever messages went in the queue will eventually come out.

But is that enough? what other concurrent aspects could be tested for here?

Also worth noting that I have already submitted the solution so whatever you suggested will not have any impact on my chances for this job I applied for.

Answer 1

Testing for thread safety is a pain as you are basically trying to prove the correctness of your program for every eventual concurrent execution. There are a few ways to go about this:

1. Formally prove the correctness of your program in the terms of the JMM. This will require you to discuss each explicit ‘happens-before’ edge in you program and how consistency is maintained based on those edges. This is possible for something as basic as a queue but becomes very complex the more functionality and edges are thrown in. I’d recommend you go through this process in any case and document your intentions/assumptions when writing concurrent code.

2. Construct test cases which demonstrate intended above behaviour by using count down latches or other means of suspending threads of execution at specific points in your program to force contention. This may turn your code into a horrible mess if taken too far but can be a very helpful technique.

3. Statistically demonstrate correctness by exercising the code over a sufficient period of time. This is the principle behind the concurrency torture suite used to verify JVM implementation correctness with regards to the JMM. This will require you to form expectations on legal/illegal states for participating threads and running your program for a long enough time on a machine with enough parallel threads. If you never hit an illegal state your program is correct :). If you run it for long enough without hitting an illegal state then in all probability you are correct.