Gary,
Did you test that this still fails on a JDK without the fix? AFAICS you
must start the threads in the correct order so that in the original bad
code the first thread in the ThreadGroup that would be stopped is
"first". Hence
64// Launch two threads as part of the same th
Captured the latest round of comments
- more readable initialization
- allow sleep interruption to terminate main thread
- added current CR# to @bug tag
24/**
25 * @test
26 * @bug 4176355 7084033
27 * @summary Stopping a ThreadGroup that contains the c
Gary,
I agree with Remi - the initialization process can be simplified as
shown. As long as first is created and started first it should do the
job. You should test that the updated test still fails on a JDK without
the fix.
I'm a little concerned about the change to wait/notify due to the f
Wow Gary, this is much better ( no thanks to my comments ;-) )
Nearly there now, please bear with us. I'll try again to be constructive
(but you may need to wait for David to come back online to confirm my
comments below :-) )
1) 'first' also needs to be volatile since it is set in one thread
On 11/08/2011 02:12 PM, Gary Adams wrote:
Let's see if this captures all the comments and
is a bit more robust in the face of the original
race conditions mentioned.
- threads are started before they are recorded in local variables
- second is now volatile
- stop thread group is trig
Let's see if this captures all the comments and
is a bit more robust in the face of the original
race conditions mentioned.
- threads are started before they are recorded in local variables
- second is now volatile
- stop thread group is triggered by first thread once second thread is
On 11/ 7/11 10:45 PM, David Holmes wrote:
On 8/11/2011 6:50 AM, Brian Goetz wrote:
Wait/notify may be better than sleeping, but semaphore/latch/barrier
are much better than wait/notify. Much.
Don't be hasty. This test is using Thread.stop - which as we all know is
a Very Bad Thing. You want
On 8/11/2011 4:28 AM, chris hegarty wrote:
In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to
coordinate between threads. So, you could completely remove the
sleep(1000) from the run method and use a
Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will
reach a p
On 8/11/2011 6:50 AM, Brian Goetz wrote:
Wait/notify may be better than sleeping, but semaphore/latch/barrier are much
better than wait/notify. Much.
Don't be hasty. This test is using Thread.stop - which as we all know is
a Very Bad Thing. You want to be very sure that anything that may be
I can recommend a good book
Sent from my iPhone
On Nov 7, 2011, at 4:53 PM, Rémi Forax wrote:
> On 11/07/2011 09:50 PM, Brian Goetz wrote:
>> Wait/notify may be better than sleeping, but semaphore/latch/barrier are
>> much better than wait/notify. Much.
>>
>> Sent from my iPhone
>
> Yea
On 11/07/2011 09:50 PM, Brian Goetz wrote:
Wait/notify may be better than sleeping, but semaphore/latch/barrier are much
better than wait/notify. Much.
Sent from my iPhone
Yeah, APIs evolve, it seems I'm to old for that s... :)
Rémi
On Nov 7, 2011, at 1:28 PM, chris hegarty wrote:
Hi
Wait/notify may be better than sleeping, but semaphore/latch/barrier are much
better than wait/notify. Much.
Sent from my iPhone
On Nov 7, 2011, at 1:28 PM, chris hegarty wrote:
> Hi Gary,
>
> Thanks for taking this bug.
>
> In similar tests I've preferred to use j.u.c.Paser/CountDownLatc
On 11/ 7/11 01:28 PM, chris hegarty wrote:
Hi Gary,
Thanks for taking this bug.
Alan was the one to suggest this as an easy starter bug.
In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to
coordinate between threads. So, you could completely remove the sleep(1000)
from th
Hi Gary,
Thanks for taking this bug.
In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to
coordinate between threads. So, you could completely remove the
sleep(1000) from the run method and use a
Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will
reach a pa
On 11/07/2011 05:03 PM, Gary Adams wrote:
Here's another test with race conditions built into the test
that can be easily avoided
CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails
intermittently
There are at least two race conditions in the test as currently written.
The tes
15 matches
Mail list logo
