commons-issues mailing list archives

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


Daniel Pitts commented on OGNL-20:

Adrian: You mean the patch I attached? I'm pretty sure none of them have "concurrency issues",
unless you mean contention issues.  I think we've decided on ConcurrentHashMap anyway, but
I'd still like to know what the issues are you see.

ConcurrentHashMap is the only solution which doesn't have contention issues under high load.
 Relieving the contention issue does leave a sort of race condition however.  Two threads
may try to create the same entry, and the work gets done multiple times.  There may be other
ways around that issue too, but my gut it is an edge case under such extreme load that it
wouldn't be the first part of the system to break-down in most cases.

The appropriate solution would be to synchronize on the key (if it is a singleton such as
Class), or create a lazy (or "Future") value which can safely be access concurrently, and
guarantees only a single thread does the work.  

> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> ---------------------------------------------------------------------
>                 Key: OGNL-20
>                 URL:
>             Project: OGNL
>          Issue Type: Improvement
>         Environment: ALL
>            Reporter: Greg Lively
>         Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
> 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