Deadlock on class locks

Tim Wilkinson tim at transvirtual.com
Tue Dec 14 18:59:59 PST 1999


Pat,

There is already a classEntry lock associated with each class - perhaps
that could be used instead of adding a new lock?

Cheers
Tim

On Tue, 14 Dec 1999, Patrick Tullmann wrote:

> > The attached test case demonstrates a deadlock in classMethod.c.
> 
> The fix was easier than I thought.  Its attached below.
> 
> > The root of the problem is that lots of code within Kaffe is using
> > the "public" class lock for internal locking.
> 
> The problem isn't actually that severe.  Most of the class locking
> happens in processClass() where conflicts with "user" code aren't
> likely (...possible(?)).  The only other bit that locks the class lock 
> is resolveString().  
> 
> The fix adds an internalLock field to each class (its a iLock ptr).
> And uses that for all "internal" class locking.  The patch also makes
> all the internal class locks explicit by using a new macro
> 'lockClass()'.
> 
> A regression test case with 'Expected Output' is included.
> 
> (BTW, please let me know if there are any problems applying the diff).
> 
> -Pat
> 
> ----- ----- ---- ---  ---  --   -    -      -         -               -
> Pat Tullmann                                       tullmann at cs.utah.edu
>        Don't hate yourself in the morning -- sleep until noon!
> 
> 



More information about the kaffe mailing list