• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L1
  • cdennis
  • Reporter: catac
  • September 11, 2008
  • 0
  • Watchers: 0
  • April 10, 2009
  • January 07, 2009



Doing thread.interrupt() on a thread trying to acquire a shared lock with lockInterruptibly() doesn’t release the blocked thread as it happens in a non-clustered environment. This happens both for ReentrantLock and ReentrantReadWriteLock.

The workaround consists in using a custom made interruptible lock based on two reentrant locks and a condition variable (await-ing on a condition is interrupted on thread.interrupt()).


Chris Dennis 2008-12-18

The fix for ReentrantLock is now in place (CDV-892). A fix for RRWL is coded (using the same solution as is now used for ReentrantLock). Some slightly more rigorous tests are required before the RRWL fix is checked-in however.

Chris Dennis 2009-01-07

ReentrantLock fix now extended to cover RRWL. Accompanying test ensures the semantics of RRWL still hold true. The ReentrantLock tests will ensure the robustness of the common code.

nadeem ghani 2009-03-12

Test with checkin is running in monkeys