8

I was investigating a deadlock and saw the following in the thread dump

at sun.awt.SunToolkit.awtLock(SunToolkit.java:229)
at sun.awt.X11.XRobotPeer.setup(Native Method)
- locked <0x00000000a633fbd0> (a java.lang.Class for sun.awt.X11.XRobotPeer)
at sun.awt.X11.XRobotPeer.<init>(XRobotPeer.java:24)
at sun.awt.X11.XToolkit.createRobot(XToolkit.java:683)
at java.awt.Robot.init(Robot.java:119)
at java.awt.Robot.<init>(Robot.java:77)

This is caused by calling Robot robot = new Robot();

This call takes a lock (SunToolkit.awtLock) and I was wondering who else is using that lock, and if it would be better if I moved that new Robot() call to the EDT. The name suggests that it is used by AWT which is single threaded. If something on the EDT takes this lock as well (e.g. a Swing component), my chances of hitting a deadlock increase when I create the Robot off the EDT.

On the other hand, as discussed in this question, a lot of the Robot methods are designed to throw an exception when called on the EDT. This would make it annoying if you would be best to create the Robot instance on the EDT.

The same problem exists for Toolkit.getDefaultToolkit().getScreenResolution() so no need to focus solely on the Robot class:

at sun.awt.SunToolkit.awtLock(SunToolkit.java:229)
at sun.awt.X11.XToolkit.getScreenResolution(XToolkit.java:999)

So what I am trying to clear up:

  • Who are the interested parties in that lock ?
  • Was that lock perhaps only introduced in an attempt to make Swing/AWT multi-threaded (or at least a bit more thread-safe), but would the recommended approach be to avoid taking that lock on another thread then the EDT ?
  • Is there any official Oracle/Sun documentation available (something like the Concurrency in Swing guide) which I can consult ? My Google skills failed me on this.
Community
  • 1
  • 1
Robin
  • 36,233
  • 5
  • 47
  • 99
  • 1
    [EDT and awt.Robot???, then please to see question](http://stackoverflow.com/questions/10468432/do-robot-methods-need-to-be-run-on-the-event-queue) by @Hovercraft Full Of Eels – mKorbel Apr 16 '13 at 11:51
  • What is the other deadlock stack? – Guillaume Polet Apr 16 '13 at 11:57
  • @GuillaumePolet The stack was weird. There were threads waiting for a lock but nobody hold the lock. We assume that it was caused by JOGL who apparently exposes that `awtLock` and uses it. But the deadlock is fixed in the mean time. I was just wondering what that awtLock does, as stated in the question – Robin Apr 16 '13 at 12:09
  • 1
    I always _assumed_ it was shared with the JNI code that manipulates the host platform's peer component, but I've never looked that far under the hood. – trashgod Apr 16 '13 at 17:30

1 Answers1

1

See the source code for SunToolkit.java here: http://www.docjar.com/html/api/sun/awt/SunToolkit.java.html the purpose of the AWT_LOCK is explained on line 208.

Here's the excerpt in case the page disappears:

/** 
 * The AWT lock is typically only used on Unix platforms to synchronize
 * access to Xlib, OpenGL, etc.  However, these methods are implemented
 * in SunToolkit so that they can be called from shared code (e.g.
 * from the OGL pipeline) or from the X11 pipeline regardless of whether
 * XToolkit or MToolkit is currently in use.  There are native macros
 * (such as AWT_LOCK) defined in awt.h, so if the implementation of these
 * methods is changed, make sure it is compatible with the native macros.
 *   
 * Note: The following methods (awtLock(), awtUnlock(), etc) should be
 * used in place of: 
 *     synchronized (getAWTLock()) {
 *         ... 
 *     }   
 *   
 * By factoring these methods out specially, we are able to change the 
 * implementation of these methods (e.g. use more advanced locking
 * mechanisms) without impacting calling code.
 *   
 * Sample usage:
 *     private void doStuffWithXlib() {
 *         assert !SunToolkit.isAWTLockHeldByCurrentThread();
 *         SunToolkit.awtLock();
 *         try {
 *             ... 
 *             XlibWrapper.XDoStuff();
 *         } finally {
 *             SunToolkit.awtUnlock();
 *         }   
 *     }   
 */
gla3dr
  • 2,179
  • 16
  • 29
lyaffe
  • 1,407
  • 15
  • 24