commons-issues mailing list archives

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


Simone Tripodi commented on OGNL-20:

Which complexity has lock/unlock objects? I'm asking because I don't know.
Can you point me please to {{ConcurrentHashMap}} doc wich explain how locks only small part
of itself and not the whole data?

Of course, Viva ultra-specialized ultra-fast concurrent collection, I just want to make sure
that, before one of us starts doing the leg-work of moving to the new implementation, it would
really add benefits to OGNL performances.

ATM I don't see much difference from

Map _methodParameterTypesCache = new HashMap();
synchronized (_methodParameterTypesCache)
    Class[] result; 

    if ( ( result = (Class[]) _methodParameterTypesCache.get( m )) == null )
        _methodParameterTypesCache.put( m, result = m.getParameterTypes() ); 
    return result; 


Map _methodParameterTypesCache = new ConcurrentHashMap();
Class[] result = _methodParameterTypesCache.puIfAbsent( m, m.getParameterTypes() );
return result; 

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.

Please provide me the info I miss, merci en avant!

> 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