Deadlock detection mechanism incorrectly assumes that thread cannot block itself

David Holmes david.holmes at oracle.com
Tue Nov 27 19:10:40 PST 2012


Thinking more on this ... it is a self-deadlock if a thread is blocked 
on an AbstractOwnableSynchronizer and the owner is that thread. That 
won't catch everything though - eg non-reentrant RWL and you tried to 
upgrade from RL to WL.

David

On 28/11/2012 12:53 PM, David Holmes wrote:
> On 28/11/2012 2:10 AM, Dmytro Sheyko wrote:
>> Hi,
>>
>> One more patch regarding deadlock detection.
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100059
>>
>> Deadlock detection mechanism assumes that thread cannot block itself. In
>> general this is not right, especially in case of non-reentrant mutexes.
>
> Arguably that is not a deadlock per se. I'm unclear in your patch as to
> what conditions actually constitute a self-deadlock and how it is
> detected. For example:
>
> Locksupport.park(); // if no one knows to unpark me I never return
>
> Object o = new Object();
> synchronized(o) { o.wait(); } // can't get notified
>
> CountdownLatch l = new CountdownLatch();
> l.await(); // no one can count down
>
> Should these be reported? I don't see how they could without much more
> elaborate analysis of the objects involved. So what constituates a
> detectable self-deadlock?
>
> Thanks,
> David
>
>
>> One of such examples we can find here (FIFOMutex sample):
>> http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/LockSupport.html
>>
>>
>> To fix this, we just need to drop unnecessary code.
>>
>> Attached updated patch and testcase
>>
>> Thanks,
>> Dmytro


More information about the hotspot-runtime-dev mailing list