commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Holger Hoffstaette" <>
Subject Re: [pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
Date Sat, 28 Oct 2006 17:29:39 GMT
On Sat, 28 Oct 2006 17:15:41 +0100, Marc Carter wrote:

>> I cannot see how a blocking borrow(key)
>> can ever continue when another thread tries to returnObject(key, object)
> borrowObject() calls Object.wait() which allows other threads access to
> the locked object (as opposed to Thread.sleep() which would not).

You are completely right, I had completely forgotten that wait() gives up
the monitor. Haven't used the manual wait/notify stuff for too long..

> returnObject() calls notifyAll() which will (when returnObject() exits)
> wake up the borrowing thread.  Hence, WHEN_EXHAUSTED_BLOCK only blocks the
> current thread from continuing execution, it does not stop others from
> returning objects or using other key pools.


> 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

Thanks again for the heads up.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message