The MultithreadedTC framework was created to make it easier to test small concurrent abstractions. It enables test designers to guarantee a specific interleaving of two or more threads, even in the presence of blocking and timing issues.

Features are:

Concurrent application designers often want to run many (unrelated or loosely related) threads of activity to maximize throughput.

MultithreadedTC is different. It supports test cases that exercise a specific interleaving of threads. This is motivated by the principle that concurrent applications should be built using small concurrent abstractions such as bounded buffers, semaphores and latches. Separating the concurrency logic from the rest of the application logic in this way makes it easier to understand and test concurrent applications. Since these abstractions are small, it should be possible to deterministically test every (significant) interleaving in separate tests.

But how can one guarantee a specific interleaving of different threads in the presence of blocking and timing issues? Consider the following example of some operations on a bounded blocking buffer (e.g. ArrayBlockingQueue) with capacity 1.

We want a test to confirm that put 17 causes Thread 1 to block until take 42 occurs in Thread 2. The test must guarantee that take 42 is not executed until after put 17. How could a designer guarantee this interleaving of the two threads? 

One approach is to use Thread.sleep() in Thread 2 to delay its first statement long enough to "guarantee" that Thread 1 has blocked. But this approach makes the test timing-dependent ― timing can be thrown off by, say, an ill-timed garbage collector. This also does not work well when stepping through the code in a debugger. 

Another common approach for coordinating activities in two threads is to use a CountDownLatch. Of course the problem is that the statement c.countDown() cannot be executed until after Thread 1 unblocks... which will not occur until Thread 2 take()s.

In other words, this test is deadlocked! The class TestFramework, provides most of the scaffolding required to run MultithreadedTC tests. It uses reflection to identify all relevant methods in the test class, invokes them simultaneously in different threads. It regulates these threads using a separate clock thread. 

The clock thread checks periodically to see if all threads are blocked. If all threads are blocked and at least one is waiting for a tick, the clock thread advances the clock to the next desired tick. The clock thread also detects deadlock (when all threads are blocked, none are waiting for a tick, and none are in state TIMED_WAITING), and can stop a test that is going on too long (a thread is in state RUNNABLE for too long.) 

The test threads are placed into a new thread group, and any threads created by these test cases will be placed in this thread group by default. All threads in the thread group will be considered by the clock thread when deciding whether to advance the clock, declare a deadlock, or stop a long-running test.class MultithreadedTestCase extends junit.framework.Assert and provides the base functionality required by all tests. (NOTE: MultithreadedTestCase does NOT extend junit.framework.TestCase). A test using this class consists of:

• an optional initialize() method,
• one or more "thread" methods which are invoked in different threads,
• an optional finish() method that is run after all threads have completed.
• runOnce(MultithreadedTestCase) -- run a test sequence once,
• runManyTimes(MultithreadedTestCase, int) -- run a test sequence as many times as specified by the int parameter, until one of the test runs fails.