This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Deadlock between Property Sheet and AWT-EventQueue | ||
---|---|---|---|
Product: | guibuilder | Reporter: | Jan Stola <jstola> |
Component: | Code | Assignee: | issues@guibuilder <issues> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | carlo.salinari, devon_c_miller, tboerkel |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jan Stola
2010-05-21 20:17:59 UTC
This is another problem caused by recent threading model change in Property Sheet. We will have to introduce a clear locking model in GUI builder to be able to bear with that change. The following comment will summarize the current knowledge in this area. LOCKS UIDefaults lock - lock used by the underlying collection (of UIDefaults) Introspector lock - lock used by Introspector when searching for (and instantiating) explicit BeanInfo of a class form-specific locks - any other lock used by GUI builder's code USE-CASES * classloading of 3rd party component - some 3rd party components modify the content of UIDefaults in their static initializer, i.e., are grabbing UIDefaults lock * BeanInfo loading of 3rd party component - instantiation of explicit BeanInfo may result in classloading of other 3rd party classes - instantiation of explicit BeanInfo is performed under Introspector lock - classloading of other 3rd party classes may attempt to grab UIDefaults lock => if any thread wants to grab both Introspector and UIDefaults locks then the order must be 'Introspector lock' before 'UIDefaults lock' * WYSIWYG look and feel in GUI builder - NetBeans IDE modifies UIDefaults to implement some UI tweaks - GUI builder reverts these modifications temporarily during painting, instantiating etc. (to implement WYSIWYG support) - GUI builder has to lock UIDefaults to avoid unwanted rollback of any (potential) additional modifications of UIDefaults (performed by other modules) - the code invoked it this 'LAF block' can result in BeanInfo loading => GUI builder has to lock Introspector as well (and must lock it before UIDefaults according to the previous use-case) * GUI builder synchronization - some GUI builder's code must be synchronized because it can be invoked from several threads - it is common that this code attempts to grab Introspector lock - it may happen that this code results in some 3rd party class loading, i.e., may attempt to grab UIDefaults lock - this code can be invoked inside or outside the 'LAF block' (mentioned in the previous use-case) - if the code is invoked in 'LAF block' then Introspector and UIDefaults locks are already grabbed by the thread => if any other thread wants to grab any of these locks then the order must be 'form-specific lock' after 'Introspector lock' and/or 'UIDefaults lock' SUMMARY If there is any chance that some thread will attempt to grab several of the following locks then they must be grabbed in the following order: 'Introspector lock' before 'UIDefaults lock' before 'form-specific lock' Fixed - getPropertySets() is called with both Introspector and UIDefaults locks grabbed. Modified files: http://hg.netbeans.org/cdev/rev/a8913ce1eabc *** Bug 187245 has been marked as a duplicate of this bug. *** *** Bug 188157 has been marked as a duplicate of this bug. *** *** Bug 190856 has been marked as a duplicate of this bug. *** |