From: Tim Wilkinson (tim@transvirtual.com)
Date: Tue Nov 17 1998 - 13:27:02 EST
Archie,
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.
Cheers
Tim
> Godmar Back writes:
> > At this point, I'm wondering why processClass takes a global lock at all
> > as opposed to simply locking the class it is currently dealing with.
>
> In general, locks correspond directly to some piece(s) of memory.
> Holding the lock permits you to examine/modify that memory. So,
> it boils down to this question: does processClass() examine/modify
> global variables that are not class specific? If not, then there's
> no need for a global lock. If there is, then what the heck are they
> and why are they needed? Perhaps they can be eliminated.
>
> Having gotten to a class-only lock, the only remaining problem
> is possible circular deadlock (e.g., two classes with static
> initializers that reference each other) but I think the JVM
> class loading algorithm is specified in such a way (with
> discrete steps) that this isn't a problem... correct?
>
> -Archie
>
> ___________________________________________________________________________
> Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
-- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:03 EDT