[rfc][icedtea-web] RH976833 ClassLoader deadlock

[Omair Majid]

On 10/04/2013 02:59 PM, Andrew Azores wrote:
> On 09/27/2013 12:42 PM, Omair Majid wrote:
>> Actually, I don't follow this. Two different threads will enter the
>> JNLPClassLoader.loadClass() method, one through CodeBaseClassLoader
>> and one through JNLPClassLoader. Shouldn't one thread block and
>> another continue? What causes the deadlock? 
> 
> See the attached PDF flow diagram, it should help clarify what's going
> on. The idea behind the patch is that t1's acquisition of cl1 is not
> strictly necessary, so removing that resolves the deadlock condition.

Thanks, that makes thing much more clearer.

> As for the rest of your response... well, I'm going to rethink this
> whole thing and try to come up with a better, higher-level solution to
> this. It is scary dealing with low-level synchronization like this,
> especially in somewhere like the JNLPClassLoader. Like I said, it's
> possible to simply use a ReentrantLock or other similar construct and
> retain the coarse-grained synch control over the
> JNLPClassLoader.loadClass method, without resorting to low-level
> synchronization on instance variables. In terms of the diagram this
> would mean introducing a new lock "r1", and causing the second box on
> the chart to cause the acquisition of r1 rather than cl1. As far as I
> can tell there's nothing really wrong with enforcing that only one
> thread enters that method at a time, the issue is just that the lock
> used for this purpose happens to be an inappropriate lock to use in this
> particular scenario.

I await the patch :)

Cheers,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681