commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [pool2] again on get rid of synchronized block
Date Mon, 12 Dec 2011 20:08:37 GMT
Hi Phil,
I haven't kept up-to-date to GKOP and GOP development for a while, so
if you feel confident about current state, I trust you :)
I'll certainly give a help to work toward the release!
All the best, have a nice day!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 12, 2011 at 8:42 PM, Phil Steitz <phil.steitz@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.  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.
>
> 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.steitz@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message