• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • Byte Code Transform
  • eng group
  • Reporter: teck
  • December 21, 2007
  • 1
  • Watchers: 0
  • December 09, 2009


ReentrantLock and ReentrantReadWriteLock both have constructors that let an application decide if they want a fair or non-fair lock policy (the default is non-fair),

The terracotta instrumentation changes this and always forces the fair policy no matter what the application passes on the constructor.

For non-shared locks instances, this seems pretty odd (especially since we’re forcing the non-default)


Chris Dennis 2009-12-09

This behavior has actually caused failures in the monkeys, as we use the instrumented forced fair RRWL in the L1 code, it actually caused a deadlock in the new lock manager code, I’m going to code a workaround for the lock manager, but I’m very keen on seeing this fixed.

Log –> http://kong.terracotta.lan/output/archive/trunk/rev14172/cruisecontrol-log-trunk-alltests-rev14172-rh5mo2-20091208-2147.log.txt.gz Archive –> http://kong.terracotta.lan/output/archive/trunk/rev14172/build-archive-trunk-alltests-rev14172-rh5mo2-20091208-2147.zip

Chris Dennis 2009-12-09

For the record the failures are due to this known “bug” (or bad specification) in the JDK 1.5 RRWL:

http://markmail.org/message/jlxczl4ilrt43kz3 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6315709