SunToolkit.awtLock: czy kod, który wykonuje taką blokadę musi być wywoływana EDT

Question

byłem bada impasu i zobaczyłem idąc zrzutu wątku

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) 

Spowodowane jest to przez wywołanie Robot robot = new Robot();

To połączenie ma blokadę (SunToolkit.awtLock) i zastanawiałem się, kto jeszcze używa tej blokady, a jeśli byłoby lepiej, gdybym przeniósł to wywołanie new Robot() do EDT. Nazwa sugeruje, że jest używany przez AWT, który jest pojedynczy wątek. Jeśli coś na EDT również bierze ten zamek (na przykład element Swing), szanse na trafienie w zakleszczenie zwiększają się, gdy tworzę z EDT.

Z drugiej strony, jak omówiono w artykule this question, wiele metod Robot jest zaprojektowanych do zgłaszania wyjątku po wywołaniu w EDT. To sprawi, że będzie irytujące, jeśli najlepiej będzie utworzyć instancję Robot w EDT. istnieje

Ten sam problem dla Toolkit.getDefaultToolkit().getScreenResolution() więc nie ma potrzeby, aby skupić się wyłącznie na klasie Robot:

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

Więc co staram się wyjaśnić:

• którzy są zainteresowani w tym zamek ?
• Czy ten zamek został wprowadzony tylko w celu wprowadzenia wielowątkowego Swing/AWT (lub co najmniej nieco bardziej wątkowego), ale czy zalecanym podejściem byłoby uniknięcie zabrania tego zamka na inny wątek, a następnie EDT?
• Czy jest dostępna oficjalna dokumentacja Oracle/Sun (coś w rodzaju Przewodnika na temat współbieżności w Swing), którą mogę skonsultować? Moje umiejętności Google zawiodły mnie w tej kwestii.

Answer 1

Zobacz kod źródłowy SunToolkit.java tutaj: http://www.docjar.com/html/api/sun/awt/SunToolkit.java.html celem AWT_LOCK wyjaśniono na linii 208.

Oto fragment, w przypadku gdy strona znika:

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