Chris Hegarty said the following on 06/23/11 20:22:
On 06/23/11 06:33 AM, David Holmes wrote:
> Sorry for the delay on this ...
>
> I concur with Mandy that using arrive() the thread must always be
> RUNNABLE or the expected next state. Hence the new check is ok.
Thanks David,
> With the
On 06/23/11 06:33 AM, David Holmes wrote:
> Sorry for the delay on this ...
>
> I concur with Mandy that using arrive() the thread must always be
> RUNNABLE or the expected next state. Hence the new check is ok.
Thanks David,
> With the new synchronization (and perhaps even the old) it seems to
David,
Thanks for taking a closer look. Really appreciate your detailed review.
On 6/23/11 1:33 PM, David Holmes wrote:
Sorry for the delay on this ...
I concur with Mandy that using arrive() the thread must always be
RUNNABLE or the expected next state. Hence the new check is ok.
With the n
Sorry for the delay on this ...
I concur with Mandy that using arrive() the thread must always be
RUNNABLE or the expected next state. Hence the new check is ok.
With the new synchronization (and perhaps even the old) it seems to me
that here:
private void setState(int newState) {
Mandy,
I need to study the test in more detail to see exactly how the thread is
supposed to change state and in what order. I'm not yet convinced that
arrive() in place of arriveAndAwaitAdvance() doesn't introduce races.
David
Mandy Chung said the following on 06/22/11 13:18:
On 6/21/11 7:
On 6/21/11 7:12 PM, Chris Hegarty wrote:
[...]
> I'm not sure the extra check in checkThreadState that the thread must
> be RUNNABLE is valid. What if you are transitioning the thread from a
> blocked to non-blocked state, you may still see it blocked on the
> first call to getState.
> L130-11
On 06/21/11 12:12 PM, Chris Hegarty wrote:
Thanks Alan, David, Mandy for you comments.
> The retry loop in checkThreadState make sense. Is the 100ms sleep a
> bit excessive? The thread will likely get to the expected state in a
> fraction of that time.
True, reduced to 10ms.
Oh, I also inc
Thanks Alan, David, Mandy for you comments.
> The retry loop in checkThreadState make sense. Is the 100ms sleep a
> bit excessive? The thread will likely get to the expected state in a
> fraction of that time.
True, reduced to 10ms.
> I'm not sure the extra check in checkThreadState that the th
Mandy Chung said the following on 06/21/11 20:08:
On 6/20/11 8:54 PM, Chris Hegarty wrote:
java/lang/Thread/ThreadStateTest.java can fail with when
checkThreadState finds an unexpected state.
Exception in thread "main" java.lang.RuntimeException: MyThread
expected to have TERMINATED but got R
Hi Chris,
On 6/20/11 8:54 PM, Chris Hegarty wrote:
java/lang/Thread/ThreadStateTest.java can fail with when
checkThreadState finds an unexpected state.
Exception in thread "main" java.lang.RuntimeException: MyThread
expected to have TERMINATED but got RUNNABLE
at ThreadStateTest.checkTh
Hi Chris,
Chris Hegarty said the following on 06/20/11 22:54:
java/lang/Thread/ThreadStateTest.java can fail with when
checkThreadState finds an unexpected state.
Exception in thread "main" java.lang.RuntimeException: MyThread expected
to have TERMINATED but got RUNNABLE
at ThreadStateTe
Chris Hegarty wrote:
java/lang/Thread/ThreadStateTest.java can fail with when
checkThreadState finds an unexpected state.
Exception in thread "main" java.lang.RuntimeException: MyThread
expected to have TERMINATED but got RUNNABLE
at ThreadStateTest.checkThreadState(ThreadStateTest.java:1
12 matches
Mail list logo
