• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • Byte Code Transform,DSO:L1,Lock Manager
  • interfaces
  • Reporter: cdennis
  • November 24, 2009
  • 0
  • Watchers: 2
  • February 12, 2014
  • February 12, 2014

Description

The new lock manager can support performing wait/notify on any lock identifier including literal locks. Currently this is disabled at the ManagerImpl level to prevent wait/notify on literals from instrumented code since their use has complex implications for both instrumentation, and TC usage patterns.

Since literal types are clustered by value and not identity, all instances of literals are implicitly clustered. When performing a wait/notify on a literal we cannot know whether other clients are also clustering the same value. This means that all wait/notify calls from instrumented classes end up becoming clustered wait/notify calls that require clustered locks around them. For current users this would mean needing to add new autolocking to their tc-config files.

There are basically four solutions to this problem that I can see (although I’m sure there are more):

  1. We permanently disable wait/notify on literals from instrumented code.
  2. We choose at execution time whether to wait/notify locally or cluster-wide depending on the type of lock that is held. This might cause confusing behavior for some users.
  3. We choose at instrumentation time whether or not to instrument wait/notify calls depending on whether the methods has an autolock applied to it. This would make doing things like bare clustered notifies impossible.
  4. We force all literal notify/wait calls from instrumented classes to be clustered and make users add the necessary autolocking.

Comments

Chris Dennis 2009-11-24

I take that back. 3 does not make clustered bare notifies impossible. You would just add an autolock to the method - even though it may have no sync in it. To me this makes 3 my favorite (assuming that 1 is out).

Hung Huynh 2014-02-12

DSO is discontinued