- A Concurrent Affair - http://www.concurrentaffair.org -

Fixed Concutest-JUnit Issues

I fixed the concurrency problems with Concutest-JUnit. The issues were pretty intricate. I changed the synchronization from a join scheme to a wait/notify scheme. The trickiest bit was getting InterruptedException for timeouts to work correctly: When the test was interrupted because of a timeout, the actual testing thread had to be interrupted as well.

Now I’m testing it with DrJava again. Unfortunately I still have to use the 3.8.2 version, since the 4.0 version isn’t entirely backward compatible, and with the 4.0 version there are a lot of needless RMI exceptions. I’m glad I added the “\_NOJOIN” extension.

The tests that fail so far are:

In the first two cases, the Concutest-JUnit error was “Thread Wait for Interactions to Exit Thread(edu.rice.cs.util.newjvm.AbstractMasterJVM$1) is still alive“. Since I couldn’t figure out how to change the behavior of DrJava quickly, I just added the “\_NOJOIN” extension.

For the next group of tests in IntegratedMasterSlaveTest, the error was “Thread Wait for SlaveJVM Exit Thread (edu.rice.cs.util.newjvm.AbstractMasterJVM$1) is still alive. Again, since I didn’t want to mess around too much with DrJava, I added “\_NOJOIN”.

For ReaderWriterLockTest I insert join() calls. The tests spawned threads, which would eventually end, but it wasn’t guaranteed that this would happen before the test ended. So I added really inconsequential join() calls.

So far, it looks like the DrJava unit tests are written pretty well. There aren’t very many flaws. One thing I plan to do, though, is to tear out the MultiThreadedTestCase that all concurrent threads ought to extend, and see what happens then, because I think that will be more like a typical testing situation.

[1] [2]Share [3]