harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey A. Ivanov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
Date Fri, 24 Aug 2007 07:20:30 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522401
] 

Alexey A. Ivanov commented on HARMONY-4624:
-------------------------------------------

Do you mean resetToPreferredSizes() is called not on Event Dispatch Thread? This is incorrect.
Generally all Swing methods are not thread-safe if the opposite is not stated if JavaDoc.
That means all operations to Swing components should be performed on the Event Dispatch Thread,
even GUI initialization. (By the way, all Sun samples and tutorial initialize GUI object on
the Event Dispatch Thread rather than Main thread.)

This way if the thread manipulating Document performs something to components, it may be a
problem. One should note Document notifies its listeners on the thread that performed a mutation.
That means that one should ensure only thread-safe Swing methods are called from Document
listeners. Possibly the default even processing somehow fails to do that which causes deadlock.

> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
>                 Key: HARMONY-4624
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4624
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>         Environment: win32
>            Reporter: Chunrong Lai
>            Assignee: Alexey Petrenko
>         Attachments: h4624.workaround.patch, HARMONY-4624-BasicSplitPaneUI.patch
>
>
>  Dead lock possibilities are seen in the synchronized metnods of AbstractDocument$ReadWriteLock.

>         public final synchronized void readLock() {
>             final Thread thread = Thread.currentThread();
>             if (writer != thread) {
>                 while (writerCount > 0) {
>                     try { wait(); } 
>                     catch (final InterruptedException e) { }
>                 }
>             }
>             readers.add(thread);
>         }
>  Waiting in synchronized methods (requires another synchronized method to wakeup it)
likely just  dies there.
>  Multithreaded SplitPane application triggers the possibility. One thread can operate
at the texts of the LeftComponent, thus in a critical section after setting writercount(writeLock()).
The other thread can operate at the rightComponent, then call the readLock() of LeftComponent
via layout managment and just waits there. 
>  Attach patch eliminates the said intra-splitpane-lock-acquirement. But it is more likely
a workaround.
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message