mazip / multithreadedtc Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/multithreadedtc
Automatically exported from code.google.com/p/multithreadedtc
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!)
Original issue reported on code.google.com by [email protected]
on 24 Aug 2011 at 9:50
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.
Original issue reported on code.google.com by [email protected]
on 11 Jun 2011 at 9:21
I'de just like to see this package become available from the maven2
repository :)
Original issue reported on code.google.com by [email protected]
on 13 May 2008 at 8:02
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.
Original issue reported on code.google.com by [email protected]
on 28 Jul 2007 at 2:17
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.
Original issue reported on code.google.com by [email protected]
on 25 Aug 2009 at 10:44
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.
Original issue reported on code.google.com by [email protected]
on 28 May 2011 at 8:04
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
Original issue reported on code.google.com by [email protected]
on 4 Nov 2009 at 9:58
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?
Original issue reported on code.google.com by [email protected]
on 26 Sep 2008 at 8:35
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.
Original issue reported on code.google.com by [email protected]
on 14 Jul 2010 at 11:57
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.
Original issue reported on code.google.com by [email protected]
on 28 May 2011 at 10:33
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.
Original issue reported on code.google.com by [email protected]
on 28 May 2011 at 10:37
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.
Original issue reported on code.google.com by [email protected]
on 21 Jan 2010 at 9:41
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 11 Jun 2011 at 9:12
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.