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

Julien Aymé commented on OGNL-20:
---------------------------------

Hi Simone !

You got it right for the main part, except that the most costly operation in 
the algorithm is the computation (or it is assumed to be so): The cost of 
accessing / comparing / puting in the map is nothing compared to the 
computation itself. That's why, the point to remove any synchronized block at 
all is to avoid the cost of the computation itself (in other threads of course, 
not in the thread which does the computation), not the cost of locking the map.

In the example you gave, the computation is:
{code}
m.getParameterTypes()
{code}
which may not be very costly... But in general, you get the idea.

Plus, ConcurrentHashMap behaves way better than using a read/write lock with an 
HashMap (due to the fact that the CHM locks only small part of itself, not the 
whole map data. Viva ultra-specialized ultra-fast concurrent collection ! :-) )


> 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


Reply via email to