Re: DO NOT REPLY [Bug 15060] -

[Leo Sutic <le...@inspireinfrastructure.com>]

I have forgotten my bugzilla password and I don't have access to the 
account I'm registered at, so I can't have it mailed to myself. Therefore - 
replying anyway!

 > Hi,
 > It is true that locks occur down in bowls of ClassLoader but this must 
be guarded
 > against. The way this has to be done is by synchronizing higher up 
something like
 > the following patch.

Peter,

if the deadlock happens inside the ClassLoader, you must synchronize on 
*all* objects that may access that CL instance. For example, consider this:

class Callee {
     /**
      * This method should be synchronized, but due to a bad coder,
      * it isn't. If two threads enter it, it will deadlock.
      */
     public void willDeadlockIfCalledConcurrently ();
}

class Caller {
     private Callee callee;

     public Caller (Callee callee) {
         this.callee = callee;
     }

     public synchronized doStuff () {
         callee.doStuff ();
     }
}

Callee callee = new Callee ();
Caller callerA = new Caller (callee);
Caller callerB = new Caller (callee);

OK, since both callerA and callerB use the same callee, it doesn't matter 
that the doStuff method is synchronized. When callerA.doStuff is entered, 
callerA is locked. But this does not prevent a thread from entering 
callerB.doStuff.

The same problem exist here - the deadlock is in the classloader, meaning 
that we must have a mutex for *all* access paths to the CL instance. I'm 
not convinced that your patch does that. Could you provide some argument 
for it?

I'm not being critical of your patch, it's just that I'm wary of adding a 
patch that may not solve the problem (we end up with 10+ patches before 
finally solving the problem, and are left to wonder just which one of them 
really did solve it).

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: DO NOT REPLY [Bug 15060] -

[Peter Donald <pe...@realityforge.org>]

On Sun, 8 Dec 2002 23:06, Leo Sutic wrote:
> if the deadlock happens inside the ClassLoader, you must synchronize on
> *all* objects that may access that CL instance. For example, consider this:

yep.

> The same problem exist here - the deadlock is in the classloader, meaning
> that we must have a mutex for *all* access paths to the CL instance. I'm
> not convinced that your patch does that. Could you provide some argument
> for it?

It does not solve it - just makes it less likely to happen. As most JVMs 
resolve .class files on load nowadays - especially with things like hotspot. 
Thus the main access to classloader occurs on initial class load.The 

ClassLoader mechanism is relatively thread-safe except when one thread becomes 
re-enters classloader (ie ClassLoader.loadClass() --> static initializer 
block --> ClassLoader.loadClass()) and another thread is in classloader.

I vaguely recall seeing the detailed explanation somewhere but can't for the 
life of me remember where.

Anyways the patch does not solve it but it will hopefully make it less likely 
occurence.

-- 
Cheers,

Peter Donald
----------------------------------------
"Liberty means responsibility. That is 
      why most men dread it." - Locke
---------------------------------------- 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>