In AbstractDocument we must not attempt to release a read lock if the
current thread also holds a write lock. That is because a thread the
holds a write lock is ignored in a readLock() request. Decrementing the
readLocks counter on readUnlock for such a thread would result in an
exception later.
2006-02-13 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/text/AbstractDocument.java
(readUnlock): Don't attempt to unlock when the current threads
also
holds a write lock.
/Roman
Index: javax/swing/text/AbstractDocument.java
===================================================================
RCS file: /cvsroot/classpath/classpath/javax/swing/text/AbstractDocument.java,v
retrieving revision 1.45
diff -u -r1.45 AbstractDocument.java
--- javax/swing/text/AbstractDocument.java 9 Feb 2006 16:57:44 -0000 1.45
+++ javax/swing/text/AbstractDocument.java 13 Feb 2006 14:09:06 -0000
@@ -646,6 +646,12 @@
// more times than you've previously called lock, but it doesn't make
// sure that the threads calling unlock were the same ones that called lock
+ // If the current thread holds the write lock, and attempted to also obtain
+ // a readLock, then numReaders hasn't been incremented and we don't need
+ // to unlock it here.
+ if (currentWriter == Thread.currentThread())
+ return;
+
// FIXME: the reference implementation throws a
// javax.swing.text.StateInvariantError here
if (numReaders == 0)
@@ -847,7 +853,7 @@
*/
protected void writeLock()
{
- if (currentWriter!= null && currentWriter.equals(Thread.currentThread()))
+ if (currentWriter != null && currentWriter.equals(Thread.currentThread()))
return;
synchronized (documentCV)
{
