Hi Simone,
Thanks for to the pointer to Sacha's test.
We could replace synchronize(cl); synchronized(this) {...}
with a synchronize() that waits on reentrantLock - need to think about it,
should be more efficient when as many threads as possible wait on a
single object.
loadClass() must still synchronize(cl) because of loadClassInternal.
This means all access to the ULR is guarded by the soft lock
currentThread which is itself guarded by the hard lock reentrantLock.
The complication is the waiting on different objects.
I'm seeing an Illegal Lock Usage on shutdown for the HTML adaptor.
I think this is because it is interrupting the thread during stop.
Regards,
Adrian
>From: "Bordet, Simone" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: RE: [JBoss-dev] UnifiedLoaderRepository deadlocks
>Date: Fri, 31 May 2002 10:07:24 +0200
>
>Hi Adrian,
>
> > 3.0RC4
> > The testsuite doesn't hang, and it passes a simple test that
> > failed on the
> > previous version (I'll add it to the testsuite this weekend +
> > other more
> > complicated tests). Thanks for applying this.
>
>I saw also HEAD passed tonight :)
>Can I sak you to link to the testsuite also a testcase that Sacha
>submitted, and that is now under testuite/.../classloader/concurrentload ?
>I am still not that familiar with the testuite :P
>
> > I think there is still a problem with the ordering for
> > findClass(String) (and possibly getURLs() - but not very likely)
> > It will lock "this" before the reentrantLock which is the opposite of
> > loadClass(String, boolean, ClassLoader).
>
>Yes, but those 2 methods are called rarely. Also, it is not possible to
>implement them just calling reentrantLock.acquire/release, as I need also
>the logic of isThreadAllowed() to set the current thread (and this would
>mean to call synchronize, but I don't have the classloader to wait on). Not
>a big deal, but on which object make the thread waiting ?
>I thought as a first try to leave them as is, to see if tha last changes
>were working.
>
> > Also is synchronizing on "lock" necessary? It is already
> > synchronized on
> > the rentrantLock for these private methods.
> > Is there a reason why these methods can't be inlined to save on stack
> > opertions?
>
>No, I guess it can be removed now.
>
>I will work on it later this afternoon, or this weekend.
>
>Thanks for the feedback !
>
>Cheers
>
>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
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
_______________________________________________________________
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
