SunToolkit.awtLock: fa il codice che assume tale blocco deve essere chiesto al EDT

Question

mi stava indagando una situazione di stallo e ho visto quanto segue nella discarica filo

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) 

questo è causato chiamando Robot robot = new Robot();

Questa chiamata richiede un blocco (SunToolkit.awtLock) e mi chiedevo chi altro sta usando quel blocco e se sarebbe meglio se trasferissi quella chiamata new Robot() all'EDT. Il nome suggerisce che è utilizzato da AWT che è a thread singolo. Se qualcosa sull'EDT prende anche questo blocco (ad es. Un componente Swing), le mie possibilità di colpire un deadlock aumentano quando creo il Robot fuori dall'EDT.

D'altra parte, come discusso in this question, molti dei metodi Robot sono progettati per generare un'eccezione quando richiamati sull'EDT. Ciò renderebbe noioso se fosse meglio creare l'istanza Robot sull'EDT.

Lo stesso problema esiste per Toolkit.getDefaultToolkit().getScreenResolution() quindi nessun bisogno di concentrarsi esclusivamente sulla classe Robot:

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

Quindi quello che sto cercando di chiarire:

• Chi sono i soggetti interessati in che serratura ?
• Questo blocco forse è stato introdotto solo nel tentativo di rendere Swing/AWT multi-thread (o almeno un po 'più thread-safe), ma l'approccio consigliato sarebbe evitare di prendere quel blocco su un altro thread dell'EDT?
• C'è qualche documentazione ufficiale Oracle/Sun disponibile (qualcosa come la guida Concurrency in Swing) che posso consultare? Le mie competenze di Google mi hanno deluso.

Answer 1

vedere il codice sorgente per SunToolkit.java qui: http://www.docjar.com/html/api/sun/awt/SunToolkit.java.html lo scopo della AWT_LOCK è spiegato sulla linea 208.

Ecco l'estratto nel caso la pagina scompare:

/** 
* 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(); 
*   } 
*  } 
*/