harmony-commits mailing list archives

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

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

Andrey Pavlenko updated HARMONY-4624:
-------------------------------------

    Attachment: HARMONY-4624-BasicSplitPaneUI.patch

When adding a component to a SplitPane the current thread also acquires AWT tree lock. Beside
that, this lock is used by the EventDispatchThread during painting. I suppose there could
be the following dead lock:
EventDispatchThread acquired write lock
your thread acquired AWT tree lock
EventDispatchThread is trying to acquire AWT tree lock -> wait
your thread is trying to acquire read lock -> wait

Chunrong, could you please try my patch? With this patch the method resetToPreferredSizes()
will be invoked from the EventDispatchThread during the next repainting of the component.

> [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