[Fwd: Deadlocked Thread State is RUNNABLE?]

Tue Nov 24 05:00:29 PST 2009

David,

> The lock of the class is not held during its own or its superclass's 

Yes, I know. I mean, let's say, artifical lock that prevents simultaneous class initialization from different threads.

The current scheme of class initialization is following:

Synchronize on the Class object that represents the
class or interface to be initialized. This involves waiting until the
current thread can obtain the lock for that object (§8.13).

If initialization by some other thread is in progress for the class or interface, then wait on this Class object (which temporarily releases the lock). When the current thread awakens from the wait, repeat this step.

If initialization is in progress for the class or
interface by the current thread, then this must be a recursive request
for initialization. Release the lock on the Class object and complete normally.

If the class or interface has already been initialized, then no further action is required. Release the lock on the Class object and complete normally.

If the Class object is in an erroneous state, then initialization is not possible. Release the lock on the Class object and throw a NoClassDefFoundError.

Otherwise, record the fact that initialization of the Class object is now in progress by the current thread and release the lock on the Class object.

Next, if the Class object represents a class
rather than an interface, and the direct superclass of this class has
not yet been initialized, then recursively perform this entire
procedure for the uninitialized superclass. If the initialization of
the direct superclass completes abruptly because of a thrown exception,
then lock this Class object, label it erroneous, notify
all waiting threads, release the lock, and complete abruptly, throwing
the same exception that resulted from the initializing the superclass.

Next, execute either the class variable initializers and
static initializers of the class or the field initializers of the
interface, in textual order, as though they were a single block, except
that final static variables and fields of interfaces whose values are compile-time constants are initialized first.

If the execution of the initializers completes normally, then lock this Class object,  label it fully initialized, notify all waiting threads, release the lock, and complete this procedure normally.

Otherwise, the initializers must have completed abruptly by throwing some exception  E. If the class of E is not Error or one of its subclasses, then create a new instance of the class ExceptionInInitializerError, with E as the argument, and use this object in place of E in the following step. But if a new instance of ExceptionInInitializerError cannot be created because an OutOfMemoryError occurs, then instead use an OutOfMemoryError object in place of E in the following step.

Lock the Class object, label it erroneous,
notify all waiting threads, release the lock, and complete this
procedure abruptly with reason E or its replacement as determined in
the previous step.

In this case if some thread started initialization of class DerivedA no other thread can execute DerivedA.<clinit>.
I have following scheme in my mind (superclass initialization is moved up):

If the Class object represents a class
rather than an interface, and the direct superclass of this class has
not yet been initialized, then recursively perform this entire
procedure for the uninitialized superclass.