"Jung , Dr. Christoph" wrote:
> IMHO, your nice patch has partly solved the problem, i.e., the issue that
> Sacha was noticing with the patch.jar NOT;-) applied. And even without
> patch.jar, it should have greatly diminished the deadlock possibilities ...
> But nevertheless, I could imagine a scenario, where a synchronized
> java.lang.ClassLoader.loadClassInternal() would lead to hang-ups:
>
> ServiceLibrary contains two classloaders CL1 and CL2.
>
> CL1 has class C1 and needs to loadClassInternal("C2") in Thread T1.
> CL2 has Class C2 and needs to loadClassInternal("C1") in Thread T2.
>
> Then there is certainly a constellation where both threads concurrently
> enter the classloaders, obtaining the respective CL locks and the
> ServiceLibrary code mutually dispatching them will block.
>
> Is that a valid scenario?
I guess I have to say that I havent really looked into
the java.lang.ClassLoader code - if I did, I could no
longer make a cleanroom reimplementation if I wanted to.
But _if_ a deadlock could occur after the changes I made
to ServiceLibraries, it would no longer involve this class,
as all library calls from it (except for calls to the
collection classes) are made without holding and locks or
synchronization.
But I dont thing this could happen anyway, unless the
ClassLoader.loadClassInternal() method holds a _class_
monitor while calling out. With an instance monitor, we
could argue as follows: Assume CL1 and CL2 are different.
If the deadlock between these two classes can occur, CL1
must use CL2 to load C2, and CL2 must use CL1 to load C1.
But that would mean that CL2 is a parent of CL1, and CL1
is a parent of CL2. I believe that circular class loader
parentage is impossible in Java.
Best Regards,
Ole Husgaard.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
