harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chunrong Lai (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
Date Wed, 15 Aug 2007 09:11:30 GMT

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

Chunrong Lai commented on HARMONY-4624:
---------------------------------------


  I agree with you that this is actually a deadlock in AbstractDocument$ReadWriteLock. It
is hard to say the code of SplitPane is incorrect. 
  But re-design a general lock in AbstractDocument is time consuming.
  As your comments of "all readLock requests should succeed", I do not think it is the case
because readLock(), writeUnlock() are both synchronized methods. So if the thread is waiting
to acquire readLock (in a synchrinized method), the writer thread can not call writeUnlock
to release the readLock requests. Like what I said "waiting in synchronized methods just dies
there." :-)
  If I misundertand the issue please kindly let me know.

best regards,
chunrong

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