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
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
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
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
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
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 test uses sleeps as a way to yield time to
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
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 chris.hega...@oracle.com wrote:
Hi Gary,
Thanks for taking this bug.
In similar tests I've preferred to use
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
I can recommend a good book
Sent from my iPhone
On Nov 7, 2011, at 4:53 PM, Rémi Forax fo...@univ-mlv.fr 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
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
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
12 matches
Mail list logo
