About JDK-6772009

David Holmes david.holmes at oracle.com
Thu Jan 5 04:42:16 UTC 2017


I think the bug in that test is that it only sets the "interrupted" flag 
if it encounters InterruptedException, but it may also have detected the 
interruption in the loop condition and then would incorrectly follow the 
!interrupted path.

David

On 5/01/2017 2:20 PM, David Holmes wrote:
> Hi chenzero,
>
> Attachments get stripped from the mailing lists so you'll need to
> include your patch inline, or else get someone to host it for you on
> cr.openjdk.java.net
>
> Thanks,
> David
>
> On 5/01/2017 2:02 PM, chen zero wrote:
>> Hi,
>> About the JDK-6772009, https://bugs.openjdk.java.net/browse/JDK-6772009
>> after some testing, I think the reason is because:
>>
>> in the run() function,
>> public final void run() {
>>      .......
>>
>>      /*
>>       * in the main thread, two threads are un-interrupted, others
>> threads
>> are interrupted.
>>       * this line, however, can not guarantee that only "un-interrupted"
>> threads can go in,
>>       * but also interrupted threads can go in,
>>       * so, the "completed" will not always == 2, might be > 2
>>       */
>>      if (n <= 0) {
>>          lock.lock();
>>          try {
>>              ++completed;
>>          }
>>          finally {
>>              lock.unlock();
>>          }
>>      }
>>      ........
>> }
>>
>>
>> because the mixing of BrokenBarrierException or InterruptedException that
>> make the test case very complex,
>> I change the code of this test case in attachment, please review.
>>
>> Thanks.
>> chenzero
>>


More information about the core-libs-dev mailing list