commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Mohr (JIRA)" <>
Subject [jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
Date Thu, 08 Jun 2006 21:29:31 GMT
    [ ] 

Gordon Mohr commented on POOL-75:

Re: (1)

I see; it seems it would be sufficient to move the "_borrowerQueue.add(Thread.currentThread());"
inside the synchronized block. 

(I believe the idea of thread-fairness is really only sensible with respect to WHEN_EXHAUSTED_BLOCK
pools -- in the others, borrowObject() never blocks, so there's never the unfair/barging risk.)

Re: (2)

This was a straight copy of the superclass code; I see that the superclass has been changed
in the SVN tree, so definitely the same fix should apply here.

Re: (3)

I hadn't considered the evictor; our use case doesn't use it, and I think the usual case where
thread fairness is important  -- rationing a small number of pool objects among a large number
of threads -- may be more likely to use non-expiring pool objects.

Looking at evict(), it appears to me that it is indeterminate whether the evictor or a blocking
borrower would get the first chance to run after an object is returned -- but also that it
doesn't need to be determinate, and any app using eviction is going to be robust about pool
objects sometimes expiring "an instant" before being requested. (That is, my concept of "thread
fairness" is orthogonal to the evictor's actions.)

Thanks for considering the patch. Do you want me to make the recommended changes and resubmit?

> [pool] GenericObjectPool not FIFO with respect to borrowing threads
> -------------------------------------------------------------------
>          Key: POOL-75
>          URL:
>      Project: Commons Pool
>         Type: Improvement

>     Versions: Nightly Builds
>  Environment: Operating System: All
> Platform: All
>     Reporter: Gordon Mohr
>     Assignee: Sandy McArthur
>     Priority: Minor

> GenericObjectPool has recently been made FIFO with respect to the managed pool
> objects -- however, it is still not FIFO with respect to threads requesting
> those objects. Specifically, because standard non-fair Java synchronization
> monitors are used, later threads may barge ahead of earlier threads that are
> already waiting for a pool object to become available. At its extreme, some
> threads can cycle objects through the pool many times while others wait
> interminable. 
> Not every application needs FIFO fairness with respect to threads, and such
> fairness implies an overhead, so it  need not be the default behavior, but it
> would be a valuable option where many threads are sharing a smaller number of
> pool objects. 
> I can submit a FairGenericObjectPool which achieves thread-fairness; it only
> requires small changes to GenericObjectPool which allow some subclass overriding.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

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

View raw message