geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Why both concurrent and backport-util-concurrent?
Date Tue, 29 Aug 2006 23:25:36 GMT
On Aug 29, 2006, at 4:13 PM, Dain Sundstrom wrote:
> Wow! I never expected you to do the conversion... very cool.

Well... I can write code... I'm not just a build system foolio :-P

> Here are the notes from my review  (I think only the first item is  
> necessary and the rest are ideas or observations):
>     I don't think we need to import the Latch class from  
> concurrent.  We should be able to use the CountDownLatch class with  
> the initial size set to 1.  This will also let us avoid the long  
> discussion on the proper way to import the code :)

Ah, I missed that, did not see CountDownLatch... I prefer that to  
importing the code.

>     It doesn't look like AbstractSinglePoolConnectionInterceptor  
> ever uses the writeLock in the ReentrantReadWriteLock so it may be  
> possible to replace that lock with a simpler ReentrantLock.


>     I never noticed that Java5 atomics only have an incrementAndGet  
> method and no increment method

Ya... no such method... I think they wanted to be explicit when the  
increment happened and what is returned.  All of the usages I could  
see don't care about the return value anyways, so we could have used  
either  incrementAndGet or getAndIncrement.

>     The changes in the configuration for the Executor in Java5 seem  
> much better.

I did run into one issue with ThreadPoolExecutor... this has no wait  
policy, and some discussion online related indicate that it was not  
added to java.util.concurrent stuff because it was not very safe or  
friendly todo... or something like that.

I was not sure exactly how to get around that and use the standard  
policies, so I wrote a wait policy that does basically the same thing  
(i think) as the wait policy for PooledExecutor.


View raw message