Thank you Martin
I had code change. I took the similar way as you do here.
Please review the code change for JDK-8025198.
Description:
Race condition exists in the test ThrowingTasks.java. We should sync
CountDownLatch.countDown and CountDownLatch.getCount.
Hi Tristan,
On 4/11/2013 10:49 AM, Tristan Yan wrote:
Thank you Martin
I had code change. I took the similar way as you do here.
Please review the code change for JDK-8025198.
Description:
Race condition exists in the test ThrowingTasks.java. We should sync
CountDownLatch.countDown and
On 4/11/2013 1:42 PM, Martin Buchholz wrote:
On Sun, Nov 3, 2013 at 5:09 PM, David Holmes david.hol...@oracle.comwrote:
Locking access to a CountDownLatch just seems inherently wrong. I get that
it is the atomicity of the two calls that we want, but this still seems
unpleasant. I've looked at
Thank you Martin
I updated the code as below
http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.02/
Thank you
On 11/04/2013 11:38 AM, Martin Buchholz wrote:
Tristan, I think your change it correct.
There are some stylistic improvements I would make:
- make lock final
- make
On 4/11/2013 4:40 PM, Martin Buchholz wrote:
David and I might prefer a fix using AtomicInteger, but I don't think
there's anything incorrect with your fix - approved. Especially if you
have seen the flakiness has gone away. (I've never seen this test fail.)
+1
David
On Sun, Nov 3, 2013
/Hi Everyone
/
/I am working on bug https://bugs.openjdk.java.net/browse/JDK-8025198.
Root cause for this bug is //there is a race condition on below code.
//there is a very small chance that when 11th thread finishes
allStarted.countDown() and before check the count, 10th thread does
