You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Chunrong Lai (JIRA)" <ji...@apache.org> on 2007/08/14 04:01:30 UTC
[jira] Created: (HARMONY-4624) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
[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
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.
[jira] Resolved: (HARMONY-4624) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko resolved HARMONY-4624.
--------------------------------------
Resolution: Fixed
Yes, I agree that this patch is more likely a workaround, but it resolves the issue at the moment without any detected regressions.
So I've committed the patch and created HARMONY-4634 to track the better patch creation.
> [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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522401 ]
Alexey A. Ivanov commented on HARMONY-4624:
-------------------------------------------
Do you mean resetToPreferredSizes() is called not on Event Dispatch Thread? This is incorrect.
Generally all Swing methods are not thread-safe if the opposite is not stated if JavaDoc. That means all operations to Swing components should be performed on the Event Dispatch Thread, even GUI initialization. (By the way, all Sun samples and tutorial initialize GUI object on the Event Dispatch Thread rather than Main thread.)
This way if the thread manipulating Document performs something to components, it may be a problem. One should note Document notifies its listeners on the thread that performed a mutation. That means that one should ensure only thread-safe Swing methods are called from Document listeners. Possibly the default even processing somehow fails to do that which causes deadlock.
> [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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519920 ]
Alexey A. Ivanov commented on HARMONY-4624:
-------------------------------------------
wait() frees object's monitor allowing other synchronized methods to be called on the instance.
> [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.
[jira] Assigned: (HARMONY-4624) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko reassigned HARMONY-4624:
----------------------------------------
Assignee: Alexey Petrenko
> [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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Andrey Pavlenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522450 ]
Andrey Pavlenko commented on HARMONY-4624:
------------------------------------------
> Do you mean resetToPreferredSizes() is called not on Event Dispatch Thread?
Yes, I suppose so and I absolutely agree with you that it is not correct.
> [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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519928 ]
Chunrong Lai commented on HARMONY-4624:
---------------------------------------
That should be case but actually it is not in my test (in Harmony?).
The application just hangs there, without calling the writeUnLock() (from the LeftComponent), after (the rightComponent) meeting the situation shown by the trace.
> [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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519896 ]
Chunrong Lai commented on HARMONY-4624:
---------------------------------------
Yes I do mean that I have two threads operates at different components of the SplitPane. I think it should be thread-safe (at least thread-safe to other VMs). But it just hangs in Harmony with below stacktrace (of the RightComponent). When it happens the thread of the LeftComponent should have increased the writercount.
I am sorry that my scenario is too large to attach here. It is also difficult to gnerate a small reproducer to represent the specific multi-threading bug.
Anyway here is the trace to readLock() (for LeftComponent) from the change of RightComponent (by resetToPreferredSizes):
javax.swing.text.AbstractDocument$ReadWriteLock.readLock(AbstractDocument.java:855)
at javax.swing.text.AbstractDocument.readLock(AbstractDocument.java:1139)
at javax.swing.text.RootView.readLock(RootView.java:295)
at javax.swing.text.RootView.getPreferredSpan(RootView.java:166)
at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:515)
at javax.swing.JComponent.getPreferredSize(JComponent.java:468)
at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:376)
at javax.swing.text.JTextComponent.getPreferredScrollableViewportSize(JTextComponent.java:1131)
at javax.swing.ViewportLayout.preferredLayoutSize(ViewportLayout.java:87)
at javax.swing.JComponent.getPreferredSize(JComponent.java:474)
at javax.swing.ScrollPaneLayout.preferredLayoutSize(ScrollPaneLayout.java:187)
at javax.swing.JComponent.getPreferredSize(JComponent.java:474)
at java.awt.BorderLayout.validateArrays(BorderLayout.java:440)
at java.awt.BorderLayout.validate(BorderLayout.java:398)
at java.awt.BorderLayout.minimumLayoutSize(BorderLayout.java:273)
at javax.swing.JComponent.getMinimumSize(JComponent.java:439)
at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.calculateContentAreaSize(BasicTabbedPaneUI.java:204)
at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.calculateSize(BasicTabbedPaneUI.java:165)
at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.minimumLayoutSize(BasicTabbedPaneUI.java:375)
at javax.swing.JComponent.getMinimumSize(JComponent.java:439)
at javax.swing.plaf.basic.BasicSplitPaneUI.getMinimumSizeOfComponent(BasicSplitPaneUI.java:857)
at javax.swing.plaf.basic.BasicSplitPaneUI.access$3(BasicSplitPaneUI.java:849)
at javax.swing.plaf.basic.BasicSplitPaneUI$BasicHorizontalLayoutManager.resetToPreferredSizes(BasicSplitPaneUI.java:276)
at javax.swing.plaf.basic.BasicSplitPaneUI$BasicHorizontalLayoutManager.addLayoutComponent(BasicSplitPaneUI.java:184)
at javax.swing.plaf.basic.BasicSplitPaneUI$BasicHorizontalLayoutManager.addLayoutComponent(BasicSplitPaneUI.java:251)
at java.awt.Container.addToLayout(Container.java:390)
at java.awt.Container.addImpl(Container.java:422)
at javax.swing.JSplitPane.addImpl(JSplitPane.java:358)
at java.awt.Container.add(Container.java:245)
at javax.swing.JSplitPane.setBottomComponent(JSplitPane.java:189)
> [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.
[jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (HARMONY-4624) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko closed HARMONY-4624.
------------------------------------
> [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.
[jira] Updated: (HARMONY-4624) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chunrong Lai updated HARMONY-4624:
----------------------------------
Attachment: h4624.workaround.patch
> [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
> 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.
[jira] Updated: (HARMONY-4624) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Andrey Pavlenko (JIRA)" <ji...@apache.org>.
[ 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.