From: Archie Cobbs (archie@whistle.com)
Date: Tue Nov 17 1998 - 23:09:39 EST
Tim Wilkinson writes:
> I think deadlock is certainly possible both with incorrect and correct code.
> The incorrect case is easy to demonstrate - suppose you have a circular
> superclass list (which Java detects and throws an exception for). If this
> list is initiated by two threads starting at different points you'll get a
> deadlock.
>
> I can't come up with a deadlock condition for normal operation off the top of
> my head (perhaps it can't happen these days) - but anyway, you still have to
> deal with the first one.
Good point. Any time some class B is involved in the verification
of class A, there's the potential for deadlock.
My knowledge of the details of class verification are sketchy,
so take this with a grain of salt.. I'm kindof guessing here.. :-)
Can these occasions be enumerated and dealt with individually?
By "occasion" or "case" I mean any time information from another
class B is needed during the loading of class file A.
For example, it seems like there are many "easy" cases where
all that's needed is to read some static information about
another class that can be gotten from the class file directly
(for example, "Does method M exist in class B?"). For these
cases, simply enclosing the check or access in question inside
a global lock should suffice, because that check or access is
guaranteed to complete relatively quickly (even if that means
reading in class B's classfile from disk).
In other words, instead of having a single global lock, have many
smaller locks that enclose the specific portions of the verification
process that involve accessing other classes. In effect, we
"push down" the global lock to a finer resolution. The hope is
that "hard" cases, like when you are required to execute class
B's static initializer, don't need to be covered by a global lock.
Would there still be "hard" cases that could not be solved
with a smaller lock?
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:03 EDT