• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Duplicate
  • serverteam
  • Reporter: tgautier
  • June 19, 2006
  • 0
  • Watchers: 0
  • July 27, 2012
  • April 06, 2007


Here is the scenario:

  • JVM 1 Thread 1acquires a lock on an object (due to a synchronized method call for example)
  • The locked object becomes shared as a DSO object
  • JVM2 Thread 1attempts to acquire the lock by calling the same synchronized method on the shared object
  • JVM2 Thread 1acuires the lock

This happens because the lock is granted before the object is shared. It is not sufficient to suggest that the object be shared and then locked, as the gap between the share and the acquisition of the lock creates a race condition (suppose that it is required that JVM Thread 1 in particular is the first thread to acquire the lock)

There is a workaround, which is to create state in the object which reflects it acquisition of the “outer lock” thus when this state is changed the “outer lock” is known to have been acquired, and thus the JVM2 Thread 1 may proceed to acquire the outer lock.


Fiona OShea 2006-08-16

This is a known issue. For Lawton we should give a better error.