You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Alexey Petrenko (JIRA)" <ji...@apache.org> on 2007/08/15 12:57:30 UTC
[jira] Created: (HARMONY-4634) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
[classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
----------------------------------------------------------------------------------
Key: HARMONY-4634
URL: https://issues.apache.org/jira/browse/HARMONY-4634
Project: Harmony
Issue Type: Bug
Components: Classlib
Environment: Win32
Reporter: Alexey Petrenko
We need a better patch for HARMONY-4624.
Here is a description from HARMONY-4624:
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-4634) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko resolved HARMONY-4634.
--------------------------------------
Resolution: Fixed
The patch has been applied.
Please verify.
> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-4634
> URL: https://issues.apache.org/jira/browse/HARMONY-4634
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Win32
> Reporter: Alexey Petrenko
> Assignee: Alexey Petrenko
> Attachments: HARMONY-4634-ReadWriteLock.patch
>
>
> We need a better patch for HARMONY-4624.
> Here is a description from HARMONY-4624:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4634) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Andrey Pavlenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrey Pavlenko updated HARMONY-4634:
-------------------------------------
Attachment: HARMONY-4634-ReadWriteLock.patch
This is a new implementation of ReadWriteLock. I've tested this implementation with a big amount of threads and there were no any dead locks detected.
> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-4634
> URL: https://issues.apache.org/jira/browse/HARMONY-4634
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Win32
> Reporter: Alexey Petrenko
> Attachments: HARMONY-4634-ReadWriteLock.patch
>
>
> We need a better patch for HARMONY-4624.
> Here is a description from HARMONY-4624:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4634) [classlib][swing]SplitPane
triggers the deadlock in AbstractDocument$ReadWriteLock
Posted by "Andrey Pavlenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527533 ]
Andrey Pavlenko commented on HARMONY-4634:
------------------------------------------
verified
> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-4634
> URL: https://issues.apache.org/jira/browse/HARMONY-4634
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Win32
> Reporter: Alexey Petrenko
> Assignee: Alexey Petrenko
> Attachments: HARMONY-4634-ReadWriteLock.patch
>
>
> We need a better patch for HARMONY-4624.
> Here is a description from HARMONY-4624:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-4634) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko reassigned HARMONY-4634:
----------------------------------------
Assignee: Alexey Petrenko
> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-4634
> URL: https://issues.apache.org/jira/browse/HARMONY-4634
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Win32
> Reporter: Alexey Petrenko
> Assignee: Alexey Petrenko
> Attachments: HARMONY-4634-ReadWriteLock.patch
>
>
> We need a better patch for HARMONY-4624.
> Here is a description from HARMONY-4624:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4634) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko updated HARMONY-4634:
-------------------------------------
Patch Info: [Patch Available]
> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-4634
> URL: https://issues.apache.org/jira/browse/HARMONY-4634
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Win32
> Reporter: Alexey Petrenko
> Assignee: Alexey Petrenko
> Attachments: HARMONY-4634-ReadWriteLock.patch
>
>
> We need a better patch for HARMONY-4624.
> Here is a description from HARMONY-4624:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-4634) [classlib][swing]SplitPane triggers
the deadlock in AbstractDocument$ReadWriteLock
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko closed HARMONY-4634.
------------------------------------
> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-4634
> URL: https://issues.apache.org/jira/browse/HARMONY-4634
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Win32
> Reporter: Alexey Petrenko
> Assignee: Alexey Petrenko
> Attachments: HARMONY-4634-ReadWriteLock.patch
>
>
> We need a better patch for HARMONY-4624.
> Here is a description from HARMONY-4624:
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.