[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Deadlock detection mechanism incorrectly assumes that thread cannot block itself
From:       dmytro_sheyko () hotmail ! com (Dmytro Sheyko)
Date:       2012-11-28 8:49:44
Message-ID: SNT137-W9E0DAC016493FB025CE318A5D0 () phx ! gbl
[Download RAW message or body]


David,

Well, this change is also a bit about code cleanup. Currently we handle cycle with \
single thread differently. Why? What is so special about single thread cycles to \
ignore them?

Can it be useful not to ignore them and treat as usual thread cycles? I think yes. \
For example, one can decide to prefer their own non-reentrant lock to standard \
ReentrantLock in order to achieve better performance.

Of course, after the change numerous deadlock cases will still remain uncovered. And \
I doubt that all cases will be covered in future. As instance, \
AbstractOwnableSynchronizer supports only single owner thread and Thread supports \
only single blocker. So the case, where single writer is blocked by two readers and \
these readers are both blocked by that writer, cannot be detected without total \
rework of deadlock detection code. But the more problematic cases is covered the \
better.

Regards,
Dmytro

> Date: Wed, 28 Nov 2012 12:53:38 +1000
> From: david.holmes at oracle.com
> To: dmytro_sheyko at hotmail.com
> CC: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Subject: Re: Deadlock detection mechanism incorrectly assumes that thread cannot \
> block itself 
> 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121128/cde9ab93/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]