Holger
Regarding "The real fix here would be to make this and other boolean
ivars volatile and the get/set methods unsynchronized" - performance
wise, would this not amount to the same thing - doesnt a volatile var
(at least in JDK 5+) force a memory barrier (sync) on a read or write?
Rory
Holger Hoffstätte (JIRA) wrote:
[ http://issues.apache.org/jira/browse/POOL-93?page=comments#action_12452547 ]
Holger Hoffstätte commented on POOL-93:
---------------------------------------
Thought about that too; AFAIK volatile is not really broken any more, at least not
for volatile reads & synchronized writes as done in the backport (see e.g.
Atomic*). Also found this:
http://www.cs.umd.edu/~pugh/java/memoryModel/archive/1888.html
Got to draw the line somewhere :-)
Maybe use the getter for 1.3.x and then assume a working volatile for 2.0? That
way we can also start relaxing other areas where possible, step by step.
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,
relaxedReturnObjectBenchmark.txt
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
