<AWT Dev> deadlock involving a mutex Lock from java.awt.EventQueue and SunToolkit.PostEventQueue
artem.ananiev at oracle.com
Mon Jul 2 11:41:43 PDT 2012
this issue, originally posted to NetBeans bugzilla, is tracked as
7159230 at bugs.sun.com:
The reason of the deadlock is clear, but the scenario to reproduce it is
unknown. As I wrote in the evaluation, it's very weird to have a call to
EQ.detachDispatchThread() on NetBeans startup. That's why the bug is
still open (but AWT team is going to fix it anyway, just the priority is
not very high). Do you have a test case to reproduce it?
On 6/28/2012 11:33 AM, Peter Levart wrote:
> This started as a bug report on the NetBeans bugzila:
> But is seems that it is caused by synchronization changes to
> java.awt.EventQueue in JDK 1.7 (JDK 1.6 seems not to be affected).
> To quote the part of the NetBeans bug:
> I think that the root of the problem is in JDK 1.7, namely in the method:
> ...where it calls SunToolkit.isPostEventQueueEmpty() while holding global
> The static method SunToolkit.isPostEventQueueEmpty() invokes a synchronized
> method on a singleton PostEventQueue object. Also other methods on this
> singleton PostEventQueue are synchronized and some of them (for example
> PostEventQueue.flush() invoked from static SunToolkit.flushPendingEvents()) are
> also synchronized and call into the java.awt.EventQueue which tries to get the
> global "pushPopLock" - hence the deadlock.
> SunToolkit.isPostEventQueueEmpty() (or any of it's methods that delegate to
> PostEventQueue singleton) should not be called while holding global
> "pushPopLock" in java.awt.EventQueue...
> My proposal to fix this bug is to rewrite the SunToolkit.PostEventQueue to use
> the same global "pushPopLock" Lock instance that java.awt.EnetQueue uses for
> it's synchronization instead of "synchronized" instance methods...
> Regards, Peter
More information about the awt-dev