Re: Relieving some ClassLoader contention in PreferredClassProvider

Peter Jones wrote:
> I can't offhand explain why there would be a difference between using
> putIfAbesnt and the simple alternative synchronized snippet you
> presented below, but I do see how the behavior you reported on
> concurrency-interest can happen with the modified implementation in
> the blog entry: the loaderFutures.remove in the first synchronized
> block can remove a mapping in more cases than you seem to be expecting
> it to-- i.e. not just when the weak reference to the loader has been
> cleared.  Consider this sequence of events:
 >
> - An invocation of this method in one thread with some key completes
>   the first synchronized block having found no entry in loaderTable for
>   the key.  It creates a FutureTask and passes the result to
>   loaderFutures.putIFAbesnt, which returns null as expected.  It will
>   then execute the FutureTask, but that hasn't happened yet.
>
> - An invocation of this method in another thread with the same key
>   enters the first synchronized block, discovers no entry in
>   loaderTable (because the first thread's FutureTask hasn't executed
>   yet), and thus invokes loaderFutures.remove with the key.  Therefore,
>   the subsequent loaderFutures.putIfAbsent will again return null.

I'll reconsider the code flow in this case, thanks Peter!

> Some other comments on the code in the blog entry:

I have made some changes from the blog.  I will review these comments further to
see what things still need to be looked at.

Having another set of eyes look at it are always thankful!

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]