Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <32014558.1187164051132.JavaMail.jira@brutus>
Date: Wed, 15 Aug 2007 00:47:31 -0700 (PDT)
From: "Alexey A. Ivanov (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
 triggers the deadlock in AbstractDocument$ReadWriteLock
In-Reply-To: <7493321.1187056890650.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Hello Chunrong,

You mean your application has two threads. One of them operates on the text in LeftComponent, the other operates in the RightComponent. And it is the second thread that starts layout. Am I right?

Can you describe your scenario in more detail?

Thanks in advance,
Alexey.

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