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