adrian simplify, ANY entry in a load should synchronize and monothread. It's the chicken approach to the problem. I am recommending the "nuclear" bomb approach we seem to move in frog leaps creating new locks at each step. The cache sync was done this way,
marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Adrian Brock |Sent: Wednesday, May 29, 2002 1:57 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-Dev] DeployServiceUnitTestCase.testDependsElement |failure | | |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 _______________________________________________________________ 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
