On 18.2.2014 18:06, Martin Buchholz wrote:
Not checking any details, but tests that want to wait for a particular
thread state are a good reason to use
volatile boolean flag;
...
while (!flag) Thread.yield();
I prefer calling Thread.yield to sleeping in this special case, in part
because I don't want to rely on the implementation of sleep, while yield is
semantically a no-op. (Also sleeping 100ms is a long time for a computer)
There were discussions for a similar fix regarding Thread.yield(). The
concern was that using Thread.yield() in a tight loop might very easily
lead to starvation on single core machines. Therefore Thread.sleep(10)
is used to be sure the flag setting thread has actually a chance to
progress.
-JB-
On Tue, Feb 18, 2014 at 8:22 AM, Jaroslav Bachorik <
jaroslav.bacho...@oracle.com> wrote:
Please, review the following test change.
Issue : https://bugs.openjdk.java.net/browse/JDK-8034168
Webrev: http://cr.openjdk.java.net/~jbachorik/8034168/webrev.00
The test fails because of falsely evaluating the thread being parked as
actually waiting on a monitor. This is because there is no difference in
java thread state for those two situations. The test is using Phaser for
synchronization between the checked and checking thread to make sure an
appropriate code section is entered before performing asserts. Then it
checks the checked thread state and waits till it becomes WAITING.
Unfortunately, when Phaser needs to wait it parks the thread and sets the
thread state to WAITING. From now on the test is in a completely random
state and the result will largely depend on timing - thus failing
intermittently.
The solution is to use an additional volatile variable to prevent falsely
indicating the park() induced WAITING state.
Thanks,
-JB-
