Re: DO NOT REPLY [Bug 15060] -

[Leo Sutic]

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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>