Hi Martin,
Thanks for the very useful links!
I will study those first...
Regards,
chenzero
On Fri, Jan 6, 2017 at 12:27 PM, Martin Buchholz
wrote:
> Hi chen,
>
> The latest versions of the code lives in jsr166 CVS
> http://g.oswego.edu/dl/concurrency-interest/
> http://gee.cs.oswego.edu/cgi-bi
Hi chen,
The latest versions of the code lives in jsr166 CVS
http://g.oswego.edu/dl/concurrency-interest/
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jtreg/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java?view=co
There's been work to make tests more robust that has was
Hi Martin,
I just curious and to get self more familiar with java.
and that's what I try to do, simplify the test case, only waiting 1 round
on the barrier
In my previous email, I said I saw BrokenCarrierException, however, it's
very rare to occur, and even I can not reproduce it now.
anyway, I wil
jtreg CancelledLockLoops is not a great test. There have been changes to
it in jdk9 and it is not known to fail currently.
But chen, why are you working on this test? If you see it failing, try
simply replacing with the jdk9 version. Otherwise, I'd like to see such
tests replaced with more focu
Any fix would have to be applied to the current code in JDK 9.
But as this is java.util.concurrent testing Martin Buchholz will likely
jump in as he and Doug Lea maintain the external versions of these tests.
I don't think BrokenBarrierException should be an issue in current test.
David
On 5
Yes, the problem is related to the interrupt, timing and combine with
BrokenBarrierException, the whole testcase very complex.
so, I change the testcase as following:
in the main:
left 2 thread Un-interrupt.
wait on the barrier. // if wait return, that means all threads
end.
Hi,
You seem to be looking at an older version of the test code.
As I said in my previous mail I think the problem is that an interrupted
thread can follow this path:
if (!interrupted) {
if (print)
System.out.printf("completed after %d millis%n",
N
I think the bug in that test is that it only sets the "interrupted" flag
if it encounters InterruptedException, but it may also have detected the
interruption in the loop condition and then would incorrectly follow the
!interrupted path.
David
On 5/01/2017 2:20 PM, David Holmes wrote:
Hi che
Hi David,
Thank you for reminding.
I post the code here.
import java.util.Arrays;
import java.util.Collections;
import java.util.Random;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.locks.ReentrantLock;
// https://bugs
Hi chenzero,
Attachments get stripped from the mailing lists so you'll need to
include your patch inline, or else get someone to host it for you on
cr.openjdk.java.net
Thanks,
David
On 5/01/2017 2:02 PM, chen zero wrote:
Hi,
About the JDK-6772009, https://bugs.openjdk.java.net/browse/JDK-67
Hi,
About the JDK-6772009, https://bugs.openjdk.java.net/browse/JDK-6772009
after some testing, I think the reason is because:
in the run() function,
public final void run() {
...
/*
* in the main thread, two threads are un-interrupted, others threads
are interrupted.
*
11 matches
Mail list logo
