On Jan 10, 2006, at 6:55 PM, email@hidden wrote:
set the priority of the thread so that it has a lower priority
than the EventQueue thread.
It is not clear to me how you should do that with invokeLater but
maybe the listed documentation makes that clear. Given that it can
be done, setting the invokeLater thread to NORM_PRIORITY I would
think you still have a potential for deadlock with the same
priority AWT-AppKit thread, even if you no longer do with the 6
priority EventQueue-0 thread.
Found one Java-level deadlock:
=============================
"Thread-39":
waiting to lock monitor 0x1802eb8 (object 0x4dc891b8, a
java.awt.EventQueue),
which is held by "AWT-AppKit"
"AWT-AppKit":
waiting to lock monitor 0x1802f90 (object 0x4dc891a0, a
sun.awt.PostEventQueue),
which is held by "Thread-39"
Java stack information for the threads listed above:
===================================================
"Thread-39":
at java.awt.EventQueue.postEventPrivate(EventQueue.java:211)
----------------------------------------------------------------------
----------------------------------------------------------------------
-------
The traces indicate the priorities...
----------------------------------------------------------------------
----------------------------------------------------------------------
-------
"Thread-39" prio=6 tid=0x00567c90 nid=0x19f9600 waiting for monitor
entry [f0d8b000..f0d8bac0]
at java.awt.EventQueue.postEventPrivate(EventQueue.java:211)
"AWT-EventQueue-0" prio=6 tid=0x0051eb70 nid=0x194ca00 waiting for
monitor entry [f100f000..f1010ac0]
at java.awt.EventQueue.setCurrentEventAndMostRecentTimeImpl
(EventQueue.java:775)
"AWT-AppKit" daemon prio=5 tid=0x0050ccd0 nid=0xa000ed68 waiting
for monitor entry [bfffd000..f0d8a4c0]
at sun.awt.PostEventQueue.postEvent(SunToolkit.java:726)
- waiting to lock <0x4dc891a0> (a sun.awt.PostEventQueue)
----------------------------------------------------------------------
----------------------------------------------------------------------
-------
Making the application thread 5 would make it less than the
EventQueue but it would still match the AWT-AppKit priority. To
completely eliminate the possibility of a deadlock between the
application thread and either of the AWT threads wouldn't it need a
priority of 4? Or the App-Kit thread should be made to match the
EventQueue thread priority of 6? But I suppose that would introduce
the possibility of the two AWT threads deadlocking themselves?
This seems a bug to me to begin with, if SwingUtilities didn't bump
the priority from the NORM value it would never conflict with the
EventQueue thread to be an issue. But given that two priority 6
threads can deadlock it seems it might still be possible for the
application at priority 5 to conflict with the remaining priority 5
AWT-AppKit thread? The AppKit thread does appear to be tied to the
EventQueue somehow
at sun.awt.PostEventQueue.postEvent(SunToolkit.java:726)
so there might be some ordering there that makes multiple 5
priorities all turn out fine I guess.
Mike Hall mikehall at spacestar dot net
http://www.spacestar.net/users/mikehall
http://sourceforge.net/projects/macnative
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
