commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maurizio Cucchiara (JIRA)" <>
Subject [jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
Date Tue, 06 Sep 2011 15:52:11 GMT


Maurizio Cucchiara commented on OGNL-20:

Hi Simone,
to answer your questions...
Which complexity has lock/unlock objects? I'm asking because I don't know.
 I am not sure I understood your question, I guess that lock and unlock are atomic.
Can you point me please to ConcurrentHashMap doc wich explain how locks only small part of
itself and not the whole data?
Please, take a look at the [implementation|],
you will see that, internally, CHM uses (and hence locks) a segment as a unit of work (where
segment is a small subset of the whole map).

except that, for what I can see, the m.getParameterTypes() that worries you, in the first
implementation is invoked only when the key is not found, in the second is always invoked.
you are right, we should clarify how much cost the computation of the final object value.
Anyway I would not unwrap the {{putIfAbsent}} invocation from the existence check:
Map _methodParameterTypesCache = new ConcurrentHashMap();
    if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
        _methodParameterTypesCache.puIfAbsent( m, result = m.getParameterTypes() ); 
return result;
There are many other aspect to take into account: for example CHM doesn't support null value.
from the javadoc:
Like Hashtable but unlike HashMap, this class does not allow null to be used as a key or value.

> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> ---------------------------------------------------------------------
>                 Key: OGNL-20
>                 URL:
>             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:


View raw message