On 10/28/06, Holger Hoffstaette <[EMAIL PROTECTED]> wrote:
On Sat, 28 Oct 2006 17:15:41 +0100, Marc Carter wrote:
> Although the wait/notify *could* be made more granular than the current
> top-level implementation, this would only be a performance issue - the
> current model will not block any other threads which can legitimately use
> the GKOP.
That was clear. I was thinking about adding a few performance-boosting
things to GKOP (less granular locking via util.concurrent, Deques etc.)
but for now I think I'll be a happy camper. It's not so much the glorified
Map that I'm after but rather the factory-backed lifecycle model. If it
were not for that I'd just have all threads grope around in a
ConcurrentMap and be done. :D
The next release of pool has a KeyedObjectPool implementation that
basically uses a monitor per key. There is a "global" monitor for
accessing the the internal pool for the key but it is very briefly
held. This code has been in waiting for too long while I hoped to find
time to optimize it some more but that free time hasn't manifested
itself. I'll move to release Pool 2 with the current trunk in the next
few days.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
