[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098029#comment-13098029
]
Simone Tripodi commented on OGNL-20:
------------------------------------
Salut Julien!
of course I understand the reasons - especially #3 is crucial - and yes
{{puIfAbsent}} would fix the concurrency issue.
Anyway, getting/setting to/from Maps always has complexity O(1), comparing null
objects has complexity O(1) - are we sure, in that specific case, that avoid
the use of a lock improves the performances so much? Moreover, reading from
{{puIfAbsent}} javadoc:
{quote}
If the specified key is not already associated with a value, associate it with
the given value. This is equivalent to
if (!map.containsKey(key))
return map.put(key, value);
else
return map.get(key);
except that the action is performed atomically.
{quote}
that doesn't look so different from the {{synchronized}} code above - unless
you tell me that {{puIfAbsent}} atomicity is implemented using
super-internal-APIs that I don't know - and avoid the lock, that's the critical
point - and for wich I apologize in advance for my ignorance.
Concluding: agreed on replacing data structures to increase code
maintainability and readability - patches are welcome and I invite you to
submit! - not sure to see performances increased in that specific case.
Good catch!
> 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
