CDV ❯ Trying to acquire the WRITE lock of a ReentrantReadWriteLock while already holding the READ lock, throws exception
-
Bug
-
Status: Open
-
2 Major
-
Resolution:
-
DSO:L1
-
-
interfaces
-
Reporter: florescu
-
June 17, 2008
-
0
-
Watchers: 1
-
December 16, 2011
-
Attachments
Description
Trying to acquire the WRITE lock of a ReentrantReadWriteLock while the calling thread is already holding the READ lock throws exception “Lock upgrade is not supported. The READ lock needs to be unlocked before a WRITE lock can be requested.” Without DSO, the tryLock call times out as per javadoc.
Comments
Tim Eck 2008-06-17
Octavian Florescu 2008-06-17
I agree, the code is at least suspicious… Lock upgrade is not supported, but the javadoc states: “Additionally, a writer can acquire the read lock, but not vice-versa. Among other applications, reentrancy can be useful when write locks are held during calls or callbacks to methods that perform reads under read locks. If a reader tries to acquire the write lock it will never succeed.”
tryLock never succeeds in this test-case, and the timeout avoids the deadlock; the current jdk behavior vis-a-vis “If a reader tries to acquire the write lock it will never succeed.” is to timeout the call versus throwing an exception. The test is a “stripped-down” version of a more complex case, where the above javadoc example is reversed: the R lock is held while calling into third party code that does call backs (on the same thread), and one of the call backs is trying to get a W lock. I am with you, maybe the code should be refactored; this initial posting was all about pointing to difference in behavior between DSO and non-DSO modes. Regards,
Tim Eck 2008-06-18
sounds good. The behavior difference is definitely a bug, thanks again for reporting it
Eric B 2010-04-01
I am encountering the same problem. My thread has a read lock and is trying to upgrade to a write lock, but gets the same error message. Has there been any work done on this issue since it was reported in 2008? I’m still seeing this problem in TC 3.1.
What workaround is there?
Thanks,
Eric
Good catch, the behavior when clustered should match the javadoc and how RRWL behaves w/o terracotta.
Unless I’m missing something however, application code that behaves like the test case (ie. lock upgrade within a thread) is guaranteed to block for time specified in the call to tryLock() and seems to be indicative of a bug in the application more than anything else. I can’t think of where this sequence of calls by the same thread would be useful. Please enlighten me if I am wrong about that
p.s. thank you very much for the complete test case, it is very helpful in making sure we’re on the same page