commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Hoffstätte (JIRA) <j...@apache.org>
Subject [jira] Commented: (POOL-93) Reduce contention by making borrow & return more independent from each other
Date Fri, 24 Nov 2006 15:34:03 GMT
    [ http://issues.apache.org/jira/browse/POOL-93?page=comments#action_12452478 ] 
            
Holger Hoffstätte commented on POOL-93:
---------------------------------------

One note on the relaxing of returnObject():
_testOnReturn is now accessed without prior synchronization, which strictly speaking is wrong.
In reality this does not matter because the value is only a configuration property and (very
likely) not changed during runtime. The real fix here would be to make this and other boolean
ivars volatile and the get/set methods unsynchronized; let me now if you would like another
patch for that. The same can be done for the int ivars, though increment/decrement must still
be properly synchronized for atomicity; with JDK 1.5 or backport these should be replaced
with Atomic(Integer/Long).
In any case using volatiles is a nice way to reduce synchronization blocks from the method
level to the appropriate section of code that actually needs to be synchronized.


> Reduce contention by making borrow & return more independent from each other
> ----------------------------------------------------------------------------
>
>                 Key: POOL-93
>                 URL: http://issues.apache.org/jira/browse/POOL-93
>             Project: Commons Pool
>          Issue Type: Improvement
>    Affects Versions: Nightly Builds
>            Reporter: Holger Hoffstätte
>         Attachments: GKOP-relaxedSyncOnReturn.patch
>
>
> Currently borrow & return are completely blocked from each other, while at least
the factory-based validation & destruction can be handled independently. A few simple
changes narrow the synchronization blocks yet retain overall correctness.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

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


Mime
View raw message