On 12 December 2011 19:42, Phil Steitz <phil.ste...@gmail.com> wrote: > On 12/12/11 12:29 PM, Simone Tripodi wrote: >> Hi Phil, >> thanks for the feedbacks! I would put some energies on [pool2] since I >> am currently in the situation I need it - of course in the meantime I >> can work with snapshots, but having a release would be definitively >> better :) >> >> So I start filling an issue and update synchronized pools in >> PoolUtils, then IMHO we should back speaking about implementing >> Read/Write policy in Pools implementation. Thoughts? > > Personally, I think the 2.0 implementations in GKOP and GOP are good > and would prefer to focus on making the final preparations for > release rather than reworking the - very tricky - locking and > synchronization semantics in those implementations.
+1 > That said, if > you or anyone else has better ideas, we can certainly look at them. > Performance and intensive concurrency testing of the code in trunk > would also be very helpful. Probably also useful to work through documenting which classes are intended to be thread-safe, immutable, etc, and then checking that they are ... For example, it looks as though GenericKeyedObjectPool is intended to be thread-safe (but this is not yet documented). However, the boolean field _lifo is not volatile, and the setter/getter are not synchronized. This means changes to the field are not guaranteed to be safely published. Of course that's not a problem if GKOP is not intended to be thread-safe. > Phil >> >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Mon, Dec 12, 2011 at 7:21 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >>> On 12/12/11 10:56 AM, Phil Steitz wrote: >>>> On 12/12/11 10:26 AM, Simone Tripodi wrote: >>>>> Hi all guys, >>>>> time ago we spoke about replacing the synchronized blocks inside >>>>> pools, maybe using different strategies like Java5 Read/Write lock (I >>>>> remind you Pool2 requires Java5) and I just started playing with >>>>> PoolUtils with the SynchronizedObjectPool[1] inner class... >>>>> Can we discuss about introducing such modifications inside pool >>>>> implementations? >>>> I would say go for it in PoolUtils. Assuming we keep these pools, >>>> we should update them as we have GOP, GKOP. Regarding the pool you >>>> mention specifically, it is a little funny in that it is designed to >>>> be fully synchronized. Make sure that whatever implementation >>>> changes you propose maintain the contract. >>> Looking at the github code, I think there may be a problem. Borrow >>> is as much a "write" operation as return - both modify the state of >>> the pool. >>> >>> Phil >>>> Phil >>>>> Many thanks in advance, all the best! >>>>> -Simo >>>>> >>>>> [1] https://gist.github.com/1468252 >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://simonetripodi.livejournal.com/ >>>>> http://twitter.com/simonetripodi >>>>> http://www.99soft.org/ >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
