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 Tue, 20 Sep 2011 15:56:09 GMT

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

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

I understand that the DCL is a broken pattern, what I suggested isn't a DCL. If you don't
understand *why* its different, then either you haven't read my posts carefully or you don't
understand why the DCL is broken.  Hopefully you re-read both that article which you posted
and my posts here are well. 

I fully understand what your concerns are about the other implementations, but I disagree
that they are real issues.  If you stipulate in the get() contract that the values may be
different for the same key, then the contract is easier to provide.  It is also not that difficult
to solve the problem you have perceived.

Let's move on and avoid a flame war. This is not the appropriate place to have these kinds
of discussions.  If you wish to continue discussing these, lets do it somewhere more appropriate
(perhaps https://groups.google.com/group/comp.lang.java.programmer/topics?pli=1)

Adrian, thank you for being concerned about this project. I want this project to succeed and
be clean; I'm glad you do too, but please don't assume I understand less than you. I've been
writing software for a *long* time, and have kept up on my reading.

I agree with your conclusion however that the ConcurrentHashMap *is* the approach we want
to take.  My refactoring doesn't work out of the box anyway because currently some of the
"cached" values depend on more than the cache key (which is also an anti-pattern, and should
be examined in another Jira).

So, let us leave this conversation at that (use ConcurrentHashMap), which hopefully will make
both you and I happy.  If you are still unhappy about the rest of the conversation, I'll be
glad to continue it comp.lang.java.programmer.  I will no long respond to such a conversation
here.

Thanks,
Daniel.

> 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
>         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: http://www.atlassian.com/software/jira

        

Mime
View raw message