Hi, Ordering the currentThread and ULR didn't fix the problem I was seeing. This might still be a valid fix?
I tried Dave Smith's -Xdebug, but I couldn't get it to deadlock in this mode after about 10 testsuite runs :-( I think I've found the problems. Problem 1 --------- A does a normal loadClass() - no lock on UCL it gets past synchronise into the main routine B does a loadClassInternal() - locks the UCL A reaches unsynchronise, aquires the reentrantLock, releases itself as the currentThread and waits on the UCL B runs synchronise which tries to aquire the reentrantLock Result A holds the reentrantLock and is waiting for the UCL B holds the UCL and is waiting for the reentrantLock Problem 2 --------- A is the current thread in the repository B does a loadClassInternal() - locks the UCL C does a loadClass, synchronise, aquires the reentrantLock, it cannot continue because A is the currentThread, it waits on the UCL B runs synchronise which tries to aquire the reentrantLock Result C holds the reentrantLock and is waiting for the UCL B holds the UCL and is waiting for the reentrantLock A will hit a problem when it tries to unsynchronise Moving the cl.notifyAll() to after the reentrantLock.release() in unsynchronize() fixes problem 1. Moving the reentrantLock.release() before the syncrhonized(cl) in synchronize() fixes problem 2 My testsuite now completes without hanging. :-) But.... // This release() must be inside the synchronization block on the classloader // to avoid that a notifyAll() will arrive before the wait() below, see unsynchronize() What problem does the notifyAll before the wait cause? Spinning? Regards, Adrian >From: "Bordet, Simone" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: RE: [JBoss-Dev] DeployServiceUnitTestCase.testDependsElement >failure >Date: Wed, 29 May 2002 14:59:15 +0200 > >Hi, > > > The hang is not predictable, but it is mostly on the > > RaTopicUnitTestCase. > > Trying to dump the threads crashes the VM, but below is the start > > of one of the dumps. It appears to be a deadlock in the > > UnifiedLoaderRepository. > > > > Looking at the code, there might be an ordering problem between > > synchronized(this) and becoming the "currentThread". > > > > e.g. > > A starts with removeClassLoader and synchronizes on the ULR > > B starts with loadClassInternal and synchronizes on the ClassLoader > > B becomes the currentThread > > B reaches the synchronized(this) in loadClass and waits on the ULR > > A sends a notification which leads to a loadClassInternal > > A isn't the currentThread and waits in synchronize(ClassLoader) > > > > Result > > A is waiting to become the currentThread (held by B) > > B is waiting on the ULR (held by A) with its classloader locked > >If that's the case, then I think there is no other choice than using the >reentrant lock for every method of ULR, so that the code is wrapped into a >try/finally (acquire/release). >Adrian, can you try the above to see if it works ? > >Thanks > >Simon > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
