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