Hi Ole & others,
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?
CGJ
-----Urspr�ngliche Nachricht-----
Von: Ole Husgaard [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 2. Oktober 2001 20:30
An: [EMAIL PROTECTED]
Betreff: Re: [JBoss-dev] The rabbit has a bug in its pelt:
org.jboss.system.URLClassLoader
"Jung , Dr. Christoph" wrote:
>
> I must correct myself! We have a principle problem, unfortunately, for
which
> I do not
> have an immediate answer right now:
>
> Actually, instead of synchronized(classLoaders) in ServiceLibraries, there
> would be the need
> to *atomically* synchronize on all instances of the set in order not to
> interfere with the ClassLoader.loadClassInternally() calls.
>
> But this is not possible with the Java synchronization mechanism, AFAIK.
Please forgive me if I am wrong - I'm not very familiar
with this code.
But isn't the only reason for synchronizing on classLoaders
that there would be problems if another thread tries to
add or remove classloaders while the Set is traversed?
If this is the case, couldn't we avoid synchronizing on it
by making ServiceLibraries.addClassLoader() and
removeClassloader() create an entire new Set?
Of course, then these methods would have to be synchronized,
and we would probably also have to synchronize on the
instance variables classes, resources, clToClassSetMap and
clToResourceSetMap, but these locks would not be held
while ClassLoader.loadClassInternally() is called.
Best Regards,
Ole Husgaard.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
