[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: MC deadlock

[adrian@jboss.org]

"adrian at jboss.org" wrote : I think I've found a problem related to this?
  | Although I haven't managed to reproduce the problem so I can't be sure
  | it is actually this issue.
  | 

I found the problem but not the solution. :-)
I think I managed to find a way to reproduce the problem by putting a Thread.sleep() i
n a key place and was able to see what was really causing the problem.

The issue is a "sneaky thread".

Thread 1: managing classloading for somebody else does some classloading
Thread 2: starts to do classloading on the same classloader
Thread 1: finishes and tries to unlock (it doesn't hold the classloader monitor - but it does hold the lock on the classloader loading tasks)
Thread 1: It releases the ReentrantLock
Thread 2: checks the ReentrantLock and decides to continue
Thread 2: can't get the classloading tasks (held by thread 1)
Thread 1: Tries to do a notifyAll() which requires the classloader monitor (held by thread 2)

So basically, we need to stop the sneaky thread 2 from continuing into the
classloading until we've done the notifyAll(). The notifyAll is only there
to improve performance so waiting threads don't block for 10 seconds
between checks on the ReentrantLock - i.e. we wake up the waiting
threads immediately after we release lock.

So, I've fixed the problem by putting the release of the ReentrantLock
inside holding the classloader monitor.
This will force the "sneaky" thread to go into the acquireLock wait
(where it will release the classloader monitor)
until the releasing has done its notifyAll() and no longer needs the classloader monitor.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129658#4129658

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129658