This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Deadlock in java.net.URLClassLoader
- From: Andrew Haley <aph at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: classpath at gnu dot org, java at gcc dot gnu dot org
- Date: Mon, 5 Sep 2005 11:54:09 +0100
- Subject: Re: Deadlock in java.net.URLClassLoader
- References: <17156.31023.613650.956641@zapata.pink><m33bp16f5w.fsf@localhost.localdomain>
Tom Tromey writes:
> >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
>
> Andrew> What happens is that one thread does ClassLoader.loadClass, which is
> Andrew> synchronized on the loader, and then URLClassLoader calls toString(),
> Andrew> which is synchronized on urlloaders.
>
> Another choice would be to simply synchronize on the loader and never
> synchronize on urlloaders. There doesn't seem to be a particular
> advantage to having two different locks here.
That sounds like an excellent soloution to the problem, and it never
occurred to me. I'll re-submit.
Andrew.