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 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-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.
* this line, however, can not guarantee that only "un-interrupted"
threads can go in,
* but also interrupted threads can go in,
* so, the "completed" will not always == 2, might be > 2
*/
if (n <= 0) {
lock.lock();
try {
++completed;
}
finally {
lock.unlock();
}
}
........
}
because the mixing of BrokenBarrierException or InterruptedException that
make the test case very complex,
I change the code of this test case in attachment, please review.
Thanks.
chenzero
