RFR 8034168: ThreadMXBean/Locks.java failed, blocked on wrong object

[Jaroslav Bachorik]

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.bachorik at 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-
>>
>