mazip / multithreadedtc Goto Github PK

To allow building higher-level abstractions, it would be useful if the clock 
tick were a long instead of an int. This would for example allow to use the 
tick as the value for a fake clock.

All TCK tests for JSR 166 were rewrited by MTC? Is there any sample code? 

Secondly, I feel confusional when testing thread pool using MTC.

I'de just like to see this package become available from the maven2 
repository :) 

We need to ensure that the tests are run for every build. Currently the ant 
build does not compile nor run the tests.

1. Move code to src/main/java
2. Move tests to src/test/java
3. Update build.xml for compatibility with the changes in 1 and 2.
4. Add pom.xml. Keep a profile for the JDK1.4 build.

What steps will reproduce the problem?
1. Execute the test mtcversion.ScheduledExecutorTest 100 times:
        public void runTest() throws Throwable {
            TestFramework.runManyTimes(this, 100);
        }

What is the expected output? What do you see instead?
The test is flaky. Sometimes it passes and sometimes it fails. With 100 
repetitions, it fails consistently.

Allow MultithreadedTestCase to register listeners of the clock tick event. The 
listeners should be notified in the clock thread (since waitForTick is the 
mechanism to be notified in a test thread).

This will allow to build other abstractions, like a fake Timer or 
ScheduledThreadPoolExecutor.

We are using MultithreadedTC for some weeks now and are very happy with it.
Unfortunately we had some difficulties running it on IBM JREs.

What steps will reproduce the problem?
1. Get a IBM Java 5 Runtime (unfortunately dififcult to get, bundled with
IBM PC or with IBM Java products, for example "Rational Application
Developer for WebSphere Software", which has a trial version
(http://www-01.ibm.com/software/awdtools/developer/application/))
2. Run Example BoundedBufferTest

What is the expected output? What do you see instead?
This test should run without errors. Instead it fails with "no progress".
When started with debug info ("-Dtunit.trace=true"), it prints:
thread 1 is in state RUNNABLE
thread 2 is in state WAITING
... and so on

Thread 1 is actually waiting because of "buf.put(17);", but reported as
runnable by an IBM JRE.

What version of the product are you using? On what operating system?
MultiThreadedTC 1.01

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511
(SR2))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-20060504 (JIT enabled)

Also tested with newer version
Java(TM) 2 Runtime Environment, Standard Edition (build
pwi32devifx-20090506 (SR9-SSU +PK76176+IZ44410+IZ44495))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows Server 2003 x86-32
j9vmwi3223ifx-20090225 (JIT enabled)

Microsoft Windows XP Professional [Version 5.1.2600]


Please provide any additional information below.

This bug is known to IBM, but will not be fixed in 1.5. As we are bound to
a special Websphere Application Server version, we cannot switch to Java 6.
Documentation of the bug can be found at
http://www-01.ibm.com/support/docview.wss?uid=swg21293565
The test works if the system property is faked to 1.4 ("-Djava.version=1.4.0")
Javadoc for Thread.getState() mentions it should not be used for
synchronization control, so this could be considered a bug in
MultithreadedTC, as you are using this method to control threads. Maybe you
could offer another possibility to handle Threads "the old way" than
checking the system property ("isJDK14" in class edu.umd.cs.mtc.TestFramework)


Thank you and best regards
Marcel Freese

The waitForTick method has an overload that takes an enum.  This makes tests 
much more readable than using ints.

But the assertTick method does not have a matching overload, so we have to 
duplicate the mapping from enum to tick index.  (And we got it wrong to start 
with!)

When I try to step through a test thread method using the eclipse debugger,
I get this error message:
org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet
6783. occurred creating step request.

I set up a simple class that writes and reads to a LinkedBlockingQueue.
Then I created a test for it with one thread reading an item, and the other
thread waiting for tick 1 before writing an item.

I put a break point on the first statement of the reader thread, but as
soon as I try to step into the method, it gives me the Timeout exception.

If I put a break point on both threads, then the test fails with this message:
java.lang.IllegalStateException: No progress
    at edu.umd.cs.mtc.TestFramework$1.run(TestFramework.java:445)

That makes sense, I guess, but how can I step through the two threads in
the debugger?

What steps will reproduce the problem?
1. Create two threads, each advancing the clock using waitForTick
2. assertTick for the tick specified in 1.
3. repeat often

What is the expected output? What do you see instead?
This should always succeed. Instead, sometimes you have an "assertion failed", 
because the clock has advanced too far.

What version of the product are you using? On what operating system?
MultithreadedTC-1.01 on Linux multiprocessor. Haven't seen this error on 
Windows XP dual core.

Please provide any additional information below.

I think there might be a race condition between the clock cycle that checks for 
blocked threads and Java scheduling the thread that should resume after 
waitForTick.

Example output (here only one thread 2 is in waitForTick(1)):

  Typical (correct case):
    thread 2 is waiting for time 1
    thread 1 is waiting for time 2
    thread 1 is in state WAITING
    thread 2 is in state WAITING
    thread 1 is in state WAITING
    thread 2 is in state WAITING
    Time is now 1
    thread 1 is waiting for time 2
    Releasing thread 2 at time 1
    thread 1 is in state WAITING
    thread 2 is in state WAITING
    thread 1 is in state WAITING
    thread 2 is in state WAITING

  Sometimes (bad case):
    thread 2 is waiting for time 1
    thread 1 is waiting for time 2
    thread 1 is in state WAITING
    thread 2 is in state WAITING
    thread 1 is in state WAITING
    thread 2 is in state WAITING
    Time is now 1
    thread 1 is waiting for time 2
    thread 1 is in state WAITING
    thread 2 is in state BLOCKED
    thread 1 is in state WAITING
    thread 2 is in state BLOCKED
    Time is now 2

In the above output one can see, that the "Releasing thread 2" message is 
missing.

What steps will reproduce the problem?
The attached patch file includes comments that characterize the problem.

There is a race condition in the original for-loop below.
Say there are two threads. t[0] is not RUNNABLE when its status is 
determined, but t[1] is RUNNABLE at that time.
Before you get around to testing t[1], it unblocks t[0] and then becomes 
blocked.
The current implementation will wrongly conclude that none of the threads 
are RUNNABLE, and
absent timed waits or deadlocks, will wrongly advance the clock. 

What is the expected output? What do you see instead?
A test which should succeed fails.

What version of the product are you using? On what operating system?
1.01

Please provide any additional information below.
I don't see how this bug can be fixed without enhancing Java. A patch file 
with a workaround that makes it extremely unlikely that you will encounter 
this bug is attached. The patch file includes comments explaining why I 
think a correct fix is not possible without enhancements to Java.

What steps will reproduce the problem?
1. Execute TestWaitForTickBlocksThread 100 times.

What is the expected output? What do you see instead?
The test is flaky. Sometimes it fails, but with a 100 repetitions it fails 
consistently.

I made some enhancements for JUnit 4. See http://
janvanbesien.blogspot.com/2009/06/modernizing-multithreadedtc-junit-4.html 
for details. I would be happy to contribute them.