commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Pitts (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
Date Fri, 09 Sep 2011 05:37:09 GMT

    [ https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101002#comment-13101002
] 

Daniel Pitts commented on OGNL-20:
----------------------------------

Simone, I never meant to imply it was Ognl by anyone other than smart people :-). I'm always
suspicious of using custom code over the Java collections classes (which were also written,
and maintained, by very smart people).  I'm suspicious of code *I've* written where I could
have used Java collections.  Which is why I was curious about the History.  If the reasoning
was about performance or some such, it may no longer be relevant (especially in light of the
concurrency issues). 

In any case, it is probably a worthwhile exercise creating a benchmark to explore the performance
characteristics amongst the existing impl, and one based on using a ConcurrentHashMap and
a plain HashMap). My guess is ConcurrentHashMap scales better, even if it might be slower
for the single-threaded use case.  For a "generic" library such as Ognl, allowing the user
the ability to plug in "high concurrent" vs "high throughput" seems like a useful feature.

> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> ---------------------------------------------------------------------
>
>                 Key: OGNL-20
>                 URL: https://issues.apache.org/jira/browse/OGNL-20
>             Project: OGNL
>          Issue Type: Improvement
>         Environment: ALL
>            Reporter: Greg Lively
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part, these synchronized
blocks are controlling access to HashMaps, etc. I believe this could be done far better using
ReentrantReadWriteLocks. ReentrantReadWriteLock allows unlimited concurrent access, and single
threads only for writes. Perfect in an environment where the ratio of reads  is far higher
than writes; which is typically the scenario for caching. Plus the access control can be tuned
for reads and writes; not just a big synchronized{} wrapping a bunch of code.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message