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 Wed, 15 Aug 2007 08:49:31 GMT

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

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

>From the stack trace I can only see that it deadlocks when adding another component to
SplitPane.

How do you know that LeftComponent has increased its writerCount? Do you use subclass of AbstractDocument
and call its writeLock() excplicitly?
In general writeLock shouldn't be held for a long time.
Also you should beware that document listeners are called on the thread that performed the
mutation of Document while writeLock is actually held.

Yeah I know that threading bugs are hard to debug and catch. Do you know how these two components
interact, what is done to text?


>From the stack trace I see a thread waits to acquire readLock because another thread holds
writeLock. As soon as that writer thread calls writeUnlock, all readLock requests should succeed.

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