Of course it might take fewer CPUs to show a difference: http://www-128.ibm.com/developerworks/java/library/j-jtp10264/
But that's in the inner loop.... and I can't think of anything in Solr that synchronizes at that low of a level. Where this could really pay off is Lucene's IndexReader.isDeleted() call that Scorers make... but Lucene is Java1.4 compatible for now. -Yonik On 6/8/06, jason rutherglen <[EMAIL PROTECTED]> wrote:
What about ReentrantLock? I like it because it cleans up sync blocks. Adds a few nice methods. Makes threading more OO. ----- Original Message ---- From: Yonik Seeley <[EMAIL PROTECTED]> To: solr-dev@lucene.apache.org; jason rutherglen <[EMAIL PROTECTED]> Sent: Thursday, June 8, 2006 1:50:45 PM Subject: Re: ReentrantReadWriteLock On 6/8/06, jason rutherglen <[EMAIL PROTECTED]> wrote: > Have the Solr team looked at using ReentrantReadWriteLock for things like LRUCache and in other places where read write locks are used? Not really... ReentrantReadWriteLocks beat normal synchronization when there are many readers, fewer writers, and heavy contention for the locks. In the case of our LRUCache, there aren't any pure readers... It's implemented with LinkedHashMap, and every lookup changes the ordering of the entries. ConcurrentHashMap is a cool class, but there is no LinkedConcurrentHashMap. If you want to develop one feel free :-) In profiling though, cache lookups aren't that significant. Are you seeing something that indicates otherwise? -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server
-- -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server
